Escalating a Production Outage Through Support
A logistics company runs its customer-facing tracking portal on AWS. At 02:00 on a Saturday, the portal begins returning errors to about 30 percent of users. The on-call engineer has basic support and can open cases, but response has been slow on prior tickets. The company has a contractual obligation to restore service within four hours and must notify customers at the two-hour mark if the outage continues. The engineer suspects a configuration change deployed the previous evening but cannot confirm quickly, and the business owner is asking whether to pay for a higher support tier now.
1. Should the company upgrade its support plan during the incident? Justify the decision.
Read the worked answer
An upgrade during an active incident is a judgement call with a real trade-off. A higher tier typically provides faster response and access to technical account resources, which matters against a four-hour contractual clock. But upgrading mid-incident involves a purchase decision that may need approval, and the new tier may not take effect instantly.
The pragmatic answer is to open the case immediately at the current tier with a clearly stated business impact and the four-hour deadline, while the business owner in parallel evaluates an upgrade. If the case sits without meaningful response past the first hour, escalate and upgrade. Waiting to upgrade before opening the case wastes the most valuable minutes; upgrading reflexively without first filing a well-scoped case may add cost without changing the outcome.
2. Draft the information the engineer should include in the case to get an effective response.
Read the worked answer
State the business impact first: customer-facing tracking portal, roughly 30 percent of users affected, contractual restoration deadline of four hours, customer notification required at two hours. Give the start time and current status. Describe the symptom precisely, including error type and which requests succeed versus fail. Note the suspected trigger: a configuration change deployed the previous evening, with the deployment time and a link to the change record.
List what has already been tried and ruled out, so support does not repeat it. Provide the affected resource identifiers and the account, and name a single technical contact plus a business contact for notifications. A case with impact, timeline, symptom, suspected cause, and prior actions gives support enough to act rather than ask clarifying questions while the clock runs.
3. The business owner asks whether to notify customers at the two-hour mark if a fix is close. Advise.
Read the worked answer
Notify at the two-hour mark as committed, even if a fix looks close. The obligation is to communicate, not to have resolved the issue, and a near-miss fix can slip. A short, factual notice that service is degraded, that the team is actively engaged, and when the next update will come protects credibility. If service is restored shortly after, send a brief follow-up confirming resolution. Skipping the notice because a fix seems imminent risks breaching the commitment and eroding trust if the fix fails, which is the worse outcome.