Zero balance stops one plan, not the account
The support ticket usually says "all proxies died." The dashboard usually says something smaller: Volume Residential is at zero while Premium Residential still has credit, or Datacenter has credit but the job's generated line points at the empty residential plan. Balances are tracked per plan, so the scope of the outage matches the scope of the depleted token.
When the plan behind a request hits zero, the gateway returns 402 Payment Required for new requests on that plan. A connection already in flight may finish, which is why the last few dashboard rows can look ragged rather than ending on a clean cutoff line.
Read the dashboard row before the exception string
A wrong password, a domain blocklist match, a target-side failure, and an empty plan can all produce the same ugly retry log. The dashboard network log row resolves that: it shows host, outcome or status code, latency, and byte total for the request. A 402 in that row identifies the gateway as the source, not the target.
When workers see 402, stop the job. Retrying an unfunded plan produces only noise and makes the first clean request after a top-up harder to spot. Pause, add credit to the plan that actually went empty, then restart with a small sample.
| Dashboard outcome | What it means | Next step |
|---|---|---|
402 | Plan credit exhausted at the gateway | Top up the depleted plan; do not retry the same queue. |
407 | Credentials rejected at the gateway | Check the username token, password, and plan name in the generated line. |
403 or block page | Gateway connected; target refused | Balance is fine. Investigate headers, pacing, or session age. |
| Timeout / no response | Route or target stalled | Test a small HTML endpoint before assuming the plan is empty. |
Top up from bytes moved, not URL count
Volume Residential is $0.89/GB and Premium Residential is $5.00/GB, billed per transferred byte. The hard part is estimating the next run from what the last run actually moved, not from the number of URLs in the queue.
Apps undercount. They report saved rows, accepted bodies, or pages that made it past the parser. Provider-metered bytes include redirects, failed responses, challenge pages, protocol overhead, and bodies the app downloaded then discarded. Near cutoff, that gap widens because failed requests still transfer data before they fail. The usage log in the dashboard exports as CSV and shows byte totals per request — that number is the one to plan from.
Recover one change at a time
Do not switch protocol, regenerate every line, change country, and top up simultaneously. Each change makes it harder to confirm whether the recovery worked and which change fixed it. Add credit to the depleted plan, run a small sample against the same host using the same plan token, and confirm the new dashboard rows show the expected plan with balance decreasing.
If the same job drains faster than expected on the next run, the question is not how much more credit to add. It is which hosts, retries, redirects, or challenge pages are consuming the meter. A zero balance is often the first point at which waste becomes impossible to ignore.
Zero balance FAQ
What does a 402 from the proxy gateway mean? The plan token used in the request username has no remaining credit. The gateway stops forwarding new requests for that plan until credit is added. Connections already in flight may finish.
Does a zero balance on one plan stop the whole account? No. Balances are tracked per plan. If Volume Residential hits zero but Premium Residential still has credit, lines using the premium token keep working.
Why do workers keep retrying after a 402? Most retry logic treats 4xx as a transient target-side block. A 402 from the proxy gateway is not transient — retrying burns no bandwidth but creates log noise and delays detection of the actual problem.
How do I estimate how much credit to add? Use the dashboard's byte totals from the previous run, not the URL count. Volume Residential is $0.89/GB and Premium Residential is $5.00/GB. Provider-metered bytes include retries, redirects, and failed responses, which the app layer usually does not count.
What is the safest recovery sequence after a zero balance? Add credit to the depleted plan, run a small sample against the same host using the same plan token, confirm new rows in the dashboard show the expected plan and that balance is decreasing, then resume the full job.
Production checks
- Alert before the balance reaches zero, not after the first 402.
- Stop workers on 402; do not retry the same queue.
- Plan credit from dashboard byte totals, not URL counts.
- Top up the specific depleted plan, not a generic balance.
- Run a small sample after top-up before resuming at full volume.