What should happen when your proxy line fails

In four years of selling mobile lines out of Singapore, nobody has ever asked me how many spare SIMs I hold.

They ask about speed. They ask which carriers. They ask whether the IP is genuinely mobile and how I prove it. Never the spares. And the spares are the number that decides what your worst day with a provider actually costs you, because on real cell hardware the failure is not the interesting part. The response is.

Every seller publishes a price, a speed and a feature list. Almost none of them publish what happens at 2am when the hardware you are renting stops doing its job. That unwritten part is the support contract. Here is mine, including the night I diagnosed a failure completely wrong.

The four things that actually break

I keep rough notes on where my hours go. The failures sort into four piles, nowhere near equal in size.

The biggest by a wide margin is a single line that stops passing usable traffic while continuing to report itself in perfect health. Modem powered. SIM registered on the network. Port listening and accepting connections. And requests through it hang or return something wrong. I call these zombies and they are most of my week.

Second is a carrier event that lands on a batch. One carrier, several lines, inside the same few minutes. A cell doing maintenance, a plan level change, or something that will never be explained to me because I am a retail subscriber and no number I can call reaches an engineer. The tell is the shape: if the failures cluster on one carrier and completely ignore the other two sitting on the same shelf and the same power, the problem is not mine.

Third is power and cabling. A hub sags under load, a supply that has been fine for eight months starts browning out, a cable develops an opinion. Ten or twenty lines drop within seconds of each other, and the signature is identical to a bad software deploy. That resemblance is what makes this class expensive.

Fourth, and the one customers never suspect, is that nothing is broken at all. The plan hit its data ceiling on the nineteenth. A renewal did not clear. An account went a day past due and the automation stopped the port. I once watched a customer spend an afternoon rewriting his scraper’s retry logic when the real answer was 702GB pulled on a plan sized for 200GB.

The class where every check passes

The zombie is the one worth understanding, because every honest health check can pass while it is happening.

The port answers. The SIM is registered. A request routed through the line to a neutral echo endpoint comes back in under a second with the correct address on the correct carrier. Every signal a monitoring system can reach says healthy. The customer’s job still fails.

Usually that is because the failure is target specific. The line works everywhere except the one destination the customer cares about, because that destination has throttled the address, or made a decision about it, or is serving it a subtly different page from the one it serves everyone else. To see that from my side I would have to be running your job against your target, carrying your session, at the moment you run it.

So liveness monitoring is close to worthless against this class, and I say that as someone who spent months improving mine. I moved from handshake checks to real application layer requests. I added second and third targets so one site having a bad afternoon could not condemn a healthy line. I added DNS path checks and exit address matching. Every one of those raised the catch rate and every one was worth building.

It never reached 100% and it never will. Detection has a ceiling that sits a long way below the number of ways a mobile line can disappoint the person renting it. Most providers know this. Very few will say it, because the alternative is admitting the status page is a comfort object.

Accept the ceiling and the question changes. It stops being how fast can this provider detect a failure and becomes how fast can they replace one.

The bill you cannot see

Instant replacement only exists if the replacement already exists. Powered, registered on the network, tested, and earning nothing.

That is the awkward part. Spare capacity is inventory that produces zero revenue by design, and the moment it starts producing revenue you no longer have any. I hold a reserve on each carrier I sell. Every card in that reserve costs its monthly, roughly $10 a line here, plus its share of power and the hardware it sits on, and it returns nothing until the night somebody needs it.

You cannot conjure it either. Ordering M1 cards and getting them activated takes about three days, every time, and there is no rushing it. So a seller who holds no reserve and promises an instant swap is promising you a three day wait in fewer syllables.

When somebody asks why a line here costs more than the cheapest offer on a forum, that gap is most of the answer. You are renting a working line and you are also renting the idle one beside it that nobody is paying for.

What a decent provider owes you

Four things, and they get harder as you go down.

Notice before you write in, at least for the classes that are detectable. A line that stops answering. An exit address that stops matching its carrier. A plan walking toward its ceiling on the twelfth of the month. If the first a provider hears of an outage is your message, that is a shop, not a service.

Hold the spare hardware, per carrier, as an actual number they can tell you.

Swap you onto equivalent hardware without an argument about fault. Equivalent means the same carrier. If you were on M1 you go back onto M1, because half the reason you chose a carrier is that your accounts have been seeing that carrier’s addresses for months. A swap to a different network is a different product, and the accounts notice even when you do not.

Then tell you what happened, in one line. The hub on that shelf failed, you are on new hardware, here is the port. People handle bad news. What they do not handle is a provider going quiet for six hours and then saying it should be working now.

The night I got it completely wrong

A customer messaged at 2am that eleven of his lines had gone dead together. All eleven were green on my dashboard: reachable, registered, response times normal.

I had shipped a change to the provisioning code that same evening, so obviously I knew what had done it. I rolled it back. Nothing improved. I rolled back the deploy before that one. Still nothing. I read logs until half past three, found nothing wrong in any of them, and started constructing a theory about the carrier blocking a range.

Then I walked down and put my hand on the rack. One shelf was cold, and every line on it was one of the eleven.

A bus powered USB hub had been failing quietly for weeks. Under light load it held. When enough modems on it drew current at the same moment it sagged, the modems dropped off the bus, and the software layer above kept reporting the last state it had seen. That is why the dashboard was green: it was reading a cached truth from devices that were no longer electrically present.

A powered hub costs about $150 and covers roughly 30 ports. I had a spare in a drawer three metres away the whole time.

The hub was the cheap part. The expensive part was ninety minutes of a paying customer’s sleep, two perfectly good deploys reverted for nothing, and a customer who did not renew the next month. He never told me why. I would not have either.

What changed afterwards was not the monitoring stack. I stopped trusting a green light produced by software talking to software, and started reading current draw per shelf, which is the one signal in the whole system that a cached state cannot fake.

Questions to ask before you pay anyone

How many spare lines do you hold per carrier? Make them give a number. An operator who genuinely holds spares knows it to the card, because it irritates them every month. “Plenty of capacity” means none.

What happens if a line goes bad on a Saturday night? The answer you want has a time in it. The answer you do not want is “open a ticket”.

Does a swap keep me on the same carrier? If the seller does not understand why you are asking, they are reselling somebody else’s pool and do not know which network you are on.

What do you do when your checks say the line is fine and I say otherwise? Almost nobody asks this and it is the one that matters.

If the pitch leads with 99.9% uptime, ask uptime of what. A port accepting a connection is not the product. No customer has ever written in to complain that a port failed to answer a knock.

Why I stopped asking customers to prove it

If someone tells me a line is failing, I move them, and I work out what happened afterwards on my own time. No screenshots, no reproduce it for me, no walking anybody through curl.

Maybe half the time the line was fine and the problem lived in their code, their browser fingerprint, or a site that had decided it did not like them that day.

I swap anyway. The argument costs me more than a spare card does, and I am the only one in that conversation who can see the rack. A provider who makes you prove it has run the same arithmetic and landed elsewhere: their support time is worth more to them than your trust. That is a legitimate way to run a business and it tells you exactly what you are buying, so listen for it before your money is in. If you want lines from someone who holds the spares and moves you first, that is what I run.

Get new guides and videos first — join the Telegram channel.