Forty minutes into an incident your team still cannot explain the failure and a managed database service is one suspect. How do you decide when to escalate to another team or to the vendor, and what makes an escalation effective rather than a handoff?

## Escalate on a clock, not on despair The reliable failure mode is escalating when the team feels stuck, because "stuck" is a feeling that arrives late, is subject to ego, and correlates badly with actual progress. Engineers are optimistic about being five minutes from the answer for hours at a time. The fix is to make escalation a scheduled event rather than an admission: at declaration time, the incident commander sets a time box — commonly on the order of 20 to 30 minutes for a high-severity incident — and when the timer fires, escalation happens regardless of how promising the current thread looks. It can always be stood down. This converts a social decision into a mechanical one, which matters because the social version is exactly what an interviewer is probing. Everyone knows they should have escalated sooner in some past outage; the candidate who describes a pre-set trigger has actually solved it. ## The arithmetic that justifies over-escalating The costs are wildly asymmetric. A false escalation costs one specialist an interrupted evening and some goodwill. A late escalation costs outage minutes multiplied by every affected customer, and in an incident that is the only currency. If you are running against a service level objective, those minutes are also error budget you do not get back. So the correct bias is unambiguous: escalate earlier than feels comfortable, and normalise standing people down without embarrassment. A team where being escalated to and finding nothing is treated as a wasted call will systematically escalate late. ## Internal escalation: the specialist and the parallel track When you pull in another team, two things must be true. First, the ask is specific: not "can you look at the database", but "between 14:02 and 14:40 UTC our p99 write latency went from 12 ms to 900 ms on this cluster; we see no change in our query mix; can you tell us what changed on your side". A specific ask gets a specific answer; a vague one gets a person reading dashboards from scratch. Second, escalation runs **in parallel** with mitigation, never instead of it. This is the most common structural mistake: the team escalates and then waits. Investigating the cause and restoring service are separate workstreams, and the mitigation track — failover, rollback, shedding load, moving traffic — continues while the specialist digs. If a mitigation ends the impact, you keep the specialist engaged for the postmortem, but the clock has stopped. ## Vendor escalation Escalating to a managed-service vendor has its own mechanics. Open the support case at the **severity you actually believe**, immediately. Downgrading later is trivial; the time you lose sitting in a lower-priority queue is not recoverable, and vendors triage on the severity field you set. Include, in the first message rather than after the first reply: the exact resource identifiers, the region, the time window in UTC with an explicit timezone, request or correlation identifiers for failing calls, the metric graphs showing the change, and what you have already eliminated. Every round trip asking you for basics costs an hour of the outage. Know before the incident what your contract actually entitles you to — response time targets and the escalation path to a named contact — and have the account or technical account manager's details in the runbook rather than hunting for them at 03:00. Also be honest in the interview about the limits: for most managed services the vendor is a source of information and occasionally a lever, but your mitigation options remain yours. A response that amounts to "we opened a ticket and waited" is not incident management. ## Escalation is not a handoff The incident commander keeps the incident. The escalated party joins the incident channel as another responder, reports into the same structure and is briefed the same way. Two failure modes come from getting this wrong: the original team disengages and stops mitigating because "the experts have it", or the escalated party starts issuing changes outside the incident's coordination and two people act on production at once. State clearly at the moment of escalation who owns the incident and where decisions are made. ## Executives and business escalation A separate axis from technical escalation: some decisions are not yours. Paying for emergency vendor support, triggering contractual or regulatory customer notification, pausing a launch, or accepting data loss to restore service faster are business calls. Escalate those as soon as they become plausible rather than when they become necessary, because the person who must make them may need time to be found, briefed and given options. Bringing leadership a decision with two costed options and a recommendation gets an answer in minutes; bringing them a situation gets a meeting.