I regularly see senior platform engineers, DevOps leads, and cloud architects ask a cloud provider to troubleshoot Terraform state, customer-managed IAM policies, or application code running on virtual machines—issues that are usually outside the provider's support scope. The response is often some version of "this is customer-managed."
For people who have opened these cases, or work somewhere that expects them to, what usually drives the decision? Is it incident or SLA pressure, a requirement to document every escalation, uncertainty about where the provider's responsibility ends, hope that support can see internal service health or undocumented issues, or simply a way to show management that all options were tried? I'm trying to understand the organizational reasoning rather than assume it is always laziness or poor troubleshooting.
4 Answers
There are also less flattering explanations. Job titles do not guarantee strong troubleshooting skills, and some people genuinely misunderstand the boundary between managed and customer-managed services. Others open a case because the documentation is poor, they have exhausted the obvious options, or they want someone else to validate their conclusion. Support contracts are expensive, so teams may reasonably use them as another resource—but that does not mean every ticket is well researched or appropriate.
In large companies, opening a case is often part of incident management rather than an expectation that the provider will fix Terraform or application code. It creates an audit trail, may be required for SLA credits, and gives leadership or customers a formal statement that the provider ruled out its own infrastructure. It also lets the engineer keep investigating while another escalation is in progress.
Exactly. A case can document that the provider layer was checked before anyone starts changing production infrastructure or explaining the incident to a customer.
Management pressure is a major factor. When production is down or a project is stuck, leaders often want to hear that a vendor case is open. It can buy the team time, demonstrate that something is being done, support a request for more headcount, or provide evidence that an expensive support contract is being used. In some organizations, managers explicitly tell engineers to open a case before continuing their own investigation.
That can be frustrating, but the ticket is sometimes a pressure valve: “the provider has been engaged, and we are continuing to troubleshoot while we wait.”
Sometimes it is a genuine last-resort diagnostic tool. During an outage, the provider may have control-plane, backend, quota, routing, or service-health visibility that customers do not. Cases can also help with throttling, quota increases, undocumented behavior, provider or API bugs, breaking changes, and emergency recovery options. Even when the root cause is on the customer side, support may identify a configuration mistake or confirm that a recent provider change is involved.
We have had cases where an IAM or infrastructure issue looked like our fault until support found a cross-service behavior that was missing from the documentation.
The best approach is usually both: provide logs, timestamps, traces, and a clear reproduction, then keep investigating internally instead of treating the support case as a substitute for debugging.