Illustration of three severity levels with progressively longer response times, beside a clock

Responsive Support

Back to Server Setup · Escalation Path · Incident Handling · Service Offerings

Defined response times based on severity, so a down production service and a minor config question aren't handled on the same timeline. A single queue fails both: the urgent thing waits behind the trivial one, and the trivial one gets an urgency it never needed.

1. Severity Is About Impact, Not Feelings

Severity has to be decidable by whoever is looking at it, at three in the morning, without a discussion. That means defining it by observable impact:

Level What it means Typical shape of the response
Critical Production down or unusable, or data at risk. Nobody can work. Minutes, any hour, until it is resolved.
High Degraded but serving, or one important function broken. There is a workaround. Within the hour, during agreed hours.
Normal Something is wrong, nothing is stopped. A request or a change. Same or next working day.
Low A question, an improvement, something to look at when there is time. Scheduled, not queued indefinitely.

Two rules keep this honest. You can always raise the severity — if something is more serious than it first appeared, it moves up without an argument. And everything cannot be critical; where it is, the levels stop meaning anything and the genuinely critical thing loses its priority.

2. Respond and Resolve Are Different Promises

A response time is a commitment that a person has taken it on and started, and it is a promise that can be kept. A resolution time is not, because how long a fix takes depends on what is broken — and a provider who guarantees one either pads it enormously or will break it.

What can be committed alongside the response: a first assessment within a stated period, and updates at a stated interval while work continues. In practice the update cadence matters as much as the initial response, because silence during an outage is what makes it feel unmanaged even when it is being worked on properly.

3. Say What the Hours Actually Are

“24/7 support” means very different things, and the difference should be written down rather than discovered:

We would rather commit to hours we can keep than advertise cover we cannot. If out-of-hours critical response is needed, that is a specific arrangement with a specific cost, not a bullet point.

4. How to Reach Us, and What to Say

Critical issues need a channel that reaches a person — phone or a paging route — not an email address. Lower severities go to the normal channel. The escalation path covers who and how.

What makes a report actionable, and worth putting in a template: what you were doing, what happened, when it started, whether anything changed recently, and whether it affects everyone or one person. “The site is down” starts a diagnosis; “checkout has returned an error for all users since about 14:20, we deployed at 14:15” nearly finishes one.

5. Measure It, and Publish the Measurement

Response commitments only mean something if they are tracked. We record time to first response and time to resolution per severity, and report against them — including when we miss. A provider who reports only the months they did well is not reporting.

What You Get