What a carrier maintenance window does to your proxy
Every mobile proxy sits behind a real SIM card, and every SIM card sits behind a real carrier network. That network gets maintained. Towers get firmware updates, core routers get patched, IP pools get rebalanced. None of this is optional, and none of it is something a proxy provider controls. If you’ve ever had a scraping job fail at 3am for no visible reason, there’s a decent chance a maintenance window was the actual cause, not your script.
This is written from the operator side. We run physical SIM racks on SingTel, M1, and StarHub, so this isn’t theory, it’s what we watch happen on our own hardware.
What a maintenance window actually is
Carriers don’t run one monolithic network. There’s the radio access network (the towers your SIM talks to), and there’s the core network (the routers, gateways, and databases that assign your device an IP address and route its traffic to the internet). A maintenance window can touch either layer.
On the radio side, a tower might get taken offline for a firmware push. Devices attached to it get handed off to a neighboring cell, or drop connection entirely until the tower comes back. On the core side, a carrier might restart a gateway that’s handling PDP sessions (the data connection your SIM negotiates when it goes online) or rebalance the IP pool that gateway hands out. Either kind of maintenance can happen with almost no public notice, because from the carrier’s perspective it’s routine infrastructure work, not an event that affects “proxy users” as a category. They’re not thinking about you. They’re thinking about their own uptime SLAs to millions of regular phone subscribers.
Why your proxy IP disappears or changes
A mobile proxy’s IP address isn’t fixed to the SIM. It’s assigned by the carrier’s gateway each time the SIM’s data session reattaches, through something called a PDP context. Normally that session stays up for hours or days and the IP holds steady. A maintenance window forces a reattach, and a reattach means a new PDP context, which usually means a new IP.
From your side, this looks like one of three things. The connection drops and comes back with a different IP. The connection drops and doesn’t come back for a period of minutes while the gateway or tower recovers. Or, less commonly, the connection stays up but with degraded throughput because traffic got rerouted through a backup path that wasn’t sized for the same load. None of these are bugs in the proxy setup. They’re the network doing exactly what it’s built to do when a piece of infrastructure needs to come down.
This is also why “sticky session” mobile proxies can still rotate unexpectedly during a maintenance window even if nobody requested a rotation. The stickiness is us holding the session open on our end. If the carrier tears down the PDP context underneath it, there’s nothing to hold onto.
What this looks like downstream
If you’re running scraping jobs, the failure mode is usually a timeout or a connection reset partway through a request, followed by either a retry succeeding on a new IP or a string of retries failing until the window passes. If you’re running browser automation with persistent sessions, cookies and login state tied to that IP can get flagged by the target site as suspicious the moment the IP changes mid-session, especially on sites that fingerprint IP-to-session consistency closely. If you’re running multi-account work across several SIMs, the annoying case is when only some of your SIMs sit on towers or gateways affected by the window and others don’t, so your accounts behave inconsistently at the exact same timestamp and it’s hard to tell if that’s the network or something else.
The common thread is that all of these look, from the application layer, like “the proxy is unstable.” What’s actually happening is a layer below the proxy software entirely, on infrastructure neither you nor we can patch around, only work around.
How to build around it
You can’t schedule your jobs to dodge maintenance windows because carriers don’t publish them for third parties, and even if they did, three carriers times however many towers means there’s no clean quiet period. What you can control is how your automation reacts when it happens.
Build retry logic that treats a connection failure as a signal to back off and retry, not a signal to hammer the same request faster. A maintenance-related drop is usually measured in seconds to low minutes, so a retry with a short delay will often just work on the next attempt once the SIM reattaches.
Don’t assume IP persistence is guaranteed for anything longer than the task actually needs. If a job depends on holding one IP for an hour, that’s a fragile assumption regardless of provider, because it depends on carrier infrastructure staying untouched for that hour. Design the job so a mid-task IP change is recoverable, not fatal.
Spread long-running or account-sensitive work across more than one SIM where it matters. A single maintenance event on one gateway won’t take down every SIM on a different tower or different carrier at the same time, so redundancy at the SIM level buys you continuity that redundancy at the software level can’t.
Log the actual failure, not just “request failed.” A connection reset, a DNS timeout, and an HTTP 403 from the target site are three different problems with three different fixes, and if your logging collapses them into one bucket you’ll spend time debugging your script for something that was a five-minute carrier event.
What we do on our end
We can’t stop a carrier maintenance window, but we can shorten how long it affects you. Our racks run enough SIMs per carrier that when one gateway or tower goes down for maintenance, only the SIMs actually behind that piece of infrastructure are affected, not the whole pool. We monitor connection state on the hardware side so a SIM that’s stuck in a bad reattach loop gets flagged and cycled rather than left silently offline. And because the SIMs are on real consumer data plans on SingTel, M1, and StarHub, the IPs you get were never going to be perfectly static in the first place. That’s the tradeoff of using a genuine mobile network instead of something built to fake one: the addressing behaves like a real phone’s does, maintenance windows included, because it is one.
If you’re building something where IP realism matters more than perfect uptime, that’s the honest tradeoff to plan around. If you’re building something where five nines of connection stability matters more than the IP being a real Singapore mobile number, a mobile proxy was never going to be the right tool regardless of maintenance windows.
The short version
A carrier maintenance window is routine infrastructure work happening on a network you don’t own, and it can reattach your SIM’s data session, hand you a new IP, or drop you for a few minutes. It’s the underlying mobile network doing normal upkeep. Plan your automation to survive short disconnects and IP changes gracefully, spread sensitive work across multiple SIMs, and log failures specifically enough to tell a maintenance blip apart from an actual problem.
If you want proxies running on real SingTel, M1, and StarHub SIMs from a farm we operate ourselves, take a look at Singapore Mobile Proxy.
Get new guides and videos first — join the Telegram channel.