Reading a provider status page during an outage
The status page is a starting point, not a verdict
When a scraping job starts throwing errors, the first instinct is to open the provider’s status page. That’s the right instinct. It’s also not enough on its own. A status page is a summary someone else wrote about their own infrastructure, updated on their own schedule, filtered through their own definition of “down.” It can be accurate and still miss the exact thing that’s breaking your job.
Running proxy pools for production scraping for years, I’ve learned to treat the status page as one input among several, not the deciding vote. Here’s how to actually read one during an outage, and what to check alongside it.
What a status page is actually built from
Most providers run their status page on a third-party tool (Statuspage, Better Uptime, Instatus, or something in-house that copies the same pattern). Underneath, it’s usually a handful of components, each with its own state, plus a running incident log.
The components matter more than the top-line banner. A page that says “All systems operational” at the top can still have a component two scrolls down marked “degraded performance” for the exact region or pool type you’re using. If a provider breaks out residential, mobile, and datacenter as separate components, or splits by region, read those individually. The single-line summary at the top is an aggregate, and aggregates round problems away. A provider with twelve components and one degraded won’t necessarily flip the headline banner to yellow.
If the provider doesn’t break anything out by component at all, that’s information too. A status page with one line for “proxy network” covering every pool and every region tells you almost nothing about whether your specific traffic is affected. It’s built for a quick glance, not for diagnosis.
Green doesn’t mean your traffic is fine
This is the part that trips people up most. A proxy network is a pool of exit nodes, and a status page component is usually reporting on the health of the control plane and a sample of that pool, not on every individual IP or every carrier a mobile proxy rides on. A provider can be entirely accurate when it says the gateway is up and authentication is working, while a meaningful slice of exit nodes in one city or on one carrier are unreachable or rotating badly.
This is especially true for residential and mobile proxies, where the exit nodes are real consumer devices and connections, not servers the provider fully controls. A carrier-side outage, a batch of exit devices going offline, or a spike in churn in one geographic pool can degrade your success rate without ever showing up as an incident, because from the provider’s monitoring vantage point the network as a whole is still functioning. Datacenter proxies are more controllable end to end, so a real outage there is more likely to show cleanly on the page, but even then a single upstream data center or subnet can be affected while the rest reports healthy.
None of this means the status page is lying. It means “operational” describes the system the provider is measuring, and your job is a narrower slice of traffic than that system.
Reading the incident timeline correctly
When there is an open incident, the stages usually follow a pattern: investigating, identified, monitoring, resolved. Each stage tells you something different about how much to trust the fix.
“Investigating” means they’ve seen the same symptom you have but don’t yet know the cause. Don’t expect a timeline yet. “Identified” means they know what’s broken, which is worth noting because it often tells you the blast radius, for example whether it’s one upstream carrier, one data center, or an authentication service that touches everything. “Monitoring” means they believe the fix is in place but haven’t confirmed it holds under load. This is the stage where it’s worth waiting for the second update before you assume you’re clear, because a fix that resolves the symptom for their internal checks doesn’t always resolve it for every regional pool at once. “Resolved” is the only stage that means stop watching, and even then it’s worth checking the postmortem or the identified cause once it’s published, since it tells you whether the same failure mode is likely to recur.
Also check the timestamps against your own logs. If your errors started forty minutes before the incident was posted, that gap is normal. Providers usually post once they’ve confirmed a pattern internally, not the second the first alert fires. If your errors started well after the incident was already resolved, the problem you’re seeing is probably not the one on the page.
Separating their outage from your outage
Before treating anything as a provider-side outage, rule out the ordinary suspects on your end, because they produce similar symptoms:
Your own network or exit path. A DNS resolver having a bad afternoon, a saturated uplink, or a firewall change on your side can look identical to a provider outage from inside your scraper’s error logs.
The target site, not the proxy. A block or a captcha wall triggered by request volume or pattern is not a proxy outage, it’s a detection response from the site being scraped, and it will show up as failures regardless of which proxy pool you route through. If switching to a completely different provider produces the same failure pattern against the same target, the proxy isn’t the variable.
Your own concurrency or rate settings. If a job was recently scaled up, some of what looks like sudden proxy instability is your own request rate outrunning the pool size or the rotation interval you’re paying for.
A quick way to separate these: hit a plain, uncontroversial endpoint through the proxy, something like a basic IP-echo service, not your actual scrape target. If that fails too, the proxy path itself is broken. If it succeeds while your real target still fails, the problem is more likely on the target’s side or in how your scraper is behaving, not the proxy network.
What to capture before you open a ticket
A ticket that says “your proxies are down” gets a slow, generic reply. A ticket with specifics gets looked at faster, because it gives the provider’s engineers something to search their own logs for instead of starting from scratch. Worth capturing as soon as you notice a problem:
The exact error code and message, not a paraphrase. A 407 (proxy authentication failed), a 502 or 503 from the gateway, and a connection timeout are three different failures with three different likely causes, and lumping them together as “not working” throws away the most useful clue you have.
Timestamps in UTC, with enough of a window to show a pattern rather than one isolated failure.
Which pool, region, and protocol you were using, since that’s exactly the detail an aggregate status page tends to hide.
A request or session ID if the provider issues one. Most gateway-based providers stamp responses with something you can hand to support so they can pull the matching log line instead of searching blind.
Whether the plain IP-echo test above succeeded or failed, since it tells them immediately whether to look at the gateway or further upstream.
Building a thinner layer of your own
Status pages lag reality by design, since someone has to notice, confirm, and publish before it appears. For anything running in production, it’s worth keeping a small synthetic check of your own: a scheduled request through each pool or region you actually use, hitting a neutral endpoint, logging success rate and latency over time. It doesn’t need to be sophisticated. What it buys you is a signal that moves in real time and is scoped to exactly the traffic you care about, instead of waiting on someone else’s dashboard to catch up to what your logs already know.
No status page, and no proxy provider, can promise a scrape will never be blocked or that a pool will never degrade. Providers vary a lot in how transparent their status pages actually are, and the only way to know how a specific one behaves is to watch it through a real incident, which is worth doing before you’re depending on it under pressure.
If you’re comparing how different providers handle outages, or you’re trying to work out which proxy type actually fits the scraping you’re doing, Proxy Scraping covers residential, mobile, and datacenter proxies from the operator’s side, with honest comparisons instead of marketing copy.
Get new guides and videos first — join the Telegram channel.