The Hardest Support Job You’ve Never Heard Of
When your car breaks down, the mechanic lifts the hood.
When your cloud app breaks, your support engineer is standing in the parking lot. Listening through a closed window. Taking notes on the sound.
That’s not a metaphor I invented to be dramatic. That’s the actual job description.
I’ve spent years doing root cause analysis on cloud platforms, and I want to explain something that almost nobody outside of cloud support understands:
This type of technical support has never really existed before.
Traditional enterprise support — Oracle, SAP, mainframe vendors — was built on access. You had a problem, an engineer showed up (remotely or physically), looked at the system, ran diagnostics, reproduced the failure. The patient was right there on the table.
Cloud platforms changed the contract entirely.
Here’s what the new contract looks like.
You own the platform. The customer owns the application. The line between those two things is invisible, disputed, and usually on fire when someone calls us.
We cannot see their code. We don’t know their deployment history. We have no idea whether their connection pool is sized correctly, whether they’re doing sync-over-async, or whether someone pushed a change at 2 a.m. and quietly went back to sleep.
We find out about that last one from the logs. If the logs exist. If they captured the right thing. If the customer configured them before the incident, not after.
What we do have are telemetry artifacts. FREBs. Memory dumps. ETW traces. Kusto tables with millions of rows of platform-level data. Tools like WinDbg, SOS, DaaS, and MEX that would impress a forensic lab.
We still can’t see the patient.
So what does the actual work look like?
It looks like receiving a memory dump from a production system at 9 p.m. on a Tuesday, loaded with managed heap objects from an application you have never seen, written by a team you have never spoken to, running a workload you can only infer from the crash signatures.
You fire up WinDbg.
You start forming hypotheses.
You start eliminating them.
It looks like staring at a FREB log that captures the exact moment a request died — but not why. The symptom is documented in exquisite detail. The cause is upstream, in the application layer, behind the line you cannot cross.
It looks like building a narrative from fragments. A spike in thread pool queue depth here. A GC pressure event there. A pattern in request timing that only becomes visible when you correlate three separate data sources that were never designed to talk to each other.
This is forensic engineering. After the fact. On someone else’s system. Under SLA pressure. At enterprise scale.
And sometimes it looks like this.
A customer calls convinced Azure has become unstable. Their application stops responding every afternoon at roughly the same time.
The platform looks healthy.
CPU looks healthy.
Memory looks healthy.
Network metrics look healthy.
The only clue is a growing thread count buried inside a memory dump.
Hours later, after walking through thread stacks, wait chains, and connection activity, a pattern emerges. Hundreds of requests are blocked waiting for database connections.
The root cause isn’t Azure.
It isn’t even SQL.
A code deployment from days earlier introduced a synchronous call into an asynchronous execution path. Everything worked perfectly until traffic crossed a specific threshold. Then the connection pool slowly exhausted itself.
We never saw the code.
We reconstructed the bug from its fingerprints.
Most engineering disciplines assume that eventually, if you dig deep enough, you’ll get access to the truth.
Cloud support doesn’t make that promise.
The code may be inaccessible. The logs may not exist. The incident may already be over by the time you arrive, and the customer can’t reproduce it.
The profession is built around extracting certainty from evidence that will always be incomplete.
There’s a human layer to this that doesn’t get enough credit.
Customers often arrive assuming the cloud is guilty. That’s not unreasonable. From their perspective, everything was working until it wasn’t, and the only thing they can’t directly control is the platform.
Your job is to follow the evidence wherever it leads. And sometimes it leads straight back to the application.
Delivering that verdict is a skill no textbook covers.
You have to be right.
You have to be able to prove it.
And you have to hand that conclusion to someone who is already having a very bad day and help them understand it without making them feel ambushed.
Diplomacy as a diagnostic output.
It’s not in the job description either.
AI has started to change parts of this problem.
Not the visibility gap. Nothing changes the visibility gap short of the customer giving you access they’re not going to give you.
But AI is becoming genuinely useful for a different reason.
The value isn’t that AI magically knows the answer.
The value is that it can hold ten clues in working memory simultaneously.
Humans are good at deep reasoning.
Machines are good at not forgetting the ninth clue while they’re examining the first.
Modern diagnostics increasingly requires both.
AI can correlate thousands of lines of telemetry, identify patterns across disconnected artifact types, and surface hypotheses worth investigating. The engineer still has to validate them. The evidence still matters.
It’s a better flashlight.
The cave is still the cave.
The thing that rarely gets said out loud in this industry is that cloud PaaS support required the invention of a new discipline.
Not a harder version of something that already existed.
Something new.
Reasoning from incomplete evidence.
Building trust across an information boundary that cannot be crossed.
Delivering technically precise conclusions under conditions that would make most engineers walk away from the keyboard.
The mechanic analogy breaks down eventually.
A mechanic, given enough time, can always lift the hood.
The hood stays closed.
The job is figuring out what happened anyway.
Azure Advice 