Something in your infrastructure pipeline starts failing. Not every time — that would be easy —
but often enough to matter. You changed nothing that should have caused it. You run it again and it
works. You run it a third time and it hangs for three hours before the platform quietly gives up.
The error, when you get one, is the most useless string in the cloud: InternalServerError.
Your first instinct, and everyone else’s, is that it’s you. That instinct is correct almost every time, which is exactly what makes the rare exception so expensive. Because when it genuinely is the platform, you’re going to have to prove it — to yourself first, then to a support engineer whose own first instinct is also that it’s you. This post is about how you build that case, and, just as importantly, when you’re allowed to stop building it.
Start by assuming it’s you
This isn’t humility for its own sake; it’s the only order that works. If you skip straight to “the platform is broken”, you’ll escalate a ticket, wait a week, and get back a polite request to check the thing you didn’t check. So you check everything first — not to be thorough for its own sake, but because ruling yourself out is the evidence. Every one of your own hypotheses you kill is a line in the case you’re eventually going to make.
In our case the failure was an Azure Container Instances deployment: an ARM template that stood up a container group with a mounted file share. The support team’s opening suggestions were entirely reasonable and entirely about our side — reserved ports, mount configuration, DNS resolution to the private endpoint. We worked through them methodically. Ports: removed, verified the container bound only what it should. File share: private endpoint approved, DNS path traced hop by hop from the VNet through the firewall to the resolved private IP, mount confirmed working. None of it fixed the hang.
Here’s the thing about that work, though: even when a fix doesn’t fix anything, it isn’t wasted. It converts “we don’t know” into “we know it isn’t that”, and a stack of ruled-out causes is what separates a credible escalation from a shrug.
Reproduce it down to a signature
Intermittent bugs are slippery because they let everyone believe whatever they already believed. The way you pin one down is to stop treating each failure as an event and start treating them as a population. What do they have in common? What’s different about the runs that succeed?
The pattern that emerged was the tell. The identical template, with the identical parameters, would sometimes succeed in a few seconds and sometimes hang open-ended — three and a half hours on one run before Azure Resource Manager marked it failed on its own. Same inputs, wildly different outputs. That single observation does a lot of work, because a bug in our configuration would be deterministic: same template, same result. Non-determinism on fixed inputs points somewhere we don’t control.
Two more observations hardened it. First, the failure reproduced identically in two separate environments — sandbox and production — which rules out a one-off corrupted resource. Second, and this is the one that closes the case, a deploy succeeded mid-investigation with a configuration we hadn’t touched, and then three consecutive deploys of that same configuration hung. If the config were wrong, the success is impossible. If the config were right, our own theory of the bug is impossible. The only explanation left is that the outcome didn’t depend on our config at all.
That’s your signature: fixed inputs, variable outcome, reproducible across environments, independent of the customer-side configuration. Write it down in exactly those terms, because that’s the sentence a platform engineer can’t wave away.
Escalate with evidence, not adjectives
A weak ticket says the service is “unreliable” and asks someone to “look into it”. A strong one hands over a case file: the correlation IDs of the failed operations, the timestamps and the duration of each hang, the list of customer-side causes you eliminated and how, and the one-line signature above. You’re not asking them to investigate from scratch; you’re asking them to confirm a conclusion you’ve already reached and made hard to dispute.
It worked. The platform team came back and confirmed it — a known control-plane issue in that region, on their side, with a documented internal mitigation. There was a workaround we could apply to bridge the gap until their fix rolled out, and it held. But the workaround is the boring part of the story and it’s since been superseded; the transferable part is everything that came before it. The reason they engaged seriously is that we’d made it easier for them to agree with us than to send us away.
Knowing when to stop
There’s a failure mode lurking on both sides of this, and it’s worth being honest about because it’s the actual decision under uncertainty at the heart of the whole exercise.
Stop building your own case too early and you become the engineer who blames the platform for every bug, burns your credibility with support, and — worse — never finds the real defect sitting in your own code. The cloud provider is a convenient defendant precisely because you can’t see inside it.
Stop too late and you’ve spent a fortnight re-checking DNS for a bug that was never yours, while the actual cost — a pipeline that’s a coin-flip every run — compounds. The judgement call is: have I ruled out enough of my own hypotheses that non-determinism is the only explanation left? Not “have I run out of ideas” — you can always invent another thing to check — but “does the evidence now point somewhere I don’t control, and would it survive a skeptical reading?” When the signature holds up to your own attempt to break it, you’ve done enough. Escalate, and hold the line.
The one-line version
When a cloud platform might be at fault, the burden of proof is on you, and rightly so — it usually is you. So rule yourself out first, methodically, because each eliminated cause is evidence. Turn a flaky failure into a precise signature: fixed inputs, variable outcome, reproducible, independent of your config. Escalate with correlation IDs and a signature, not with adjectives. And treat “is it me or is it them” as a real decision with a cost on both sides — the skill isn’t proving it’s the platform, it’s knowing when you’ve proven it.