Incident Escalation and Communication

Most colocation evaluations examine the uptime guarantee closely and the incident process barely at all. That is the wrong way round for anyone whose workloads matter, because the guarantee describes what a provider owes you afterwards, while escalation and communication describe what you can actually do during the event.

Those are different things. A tenant can receive every service credit they are entitled to and still have spent four hours unable to tell their own customers anything useful.

Severity classification comes first

Everything downstream depends on how an event is classified, because severity determines who is woken, how fast, and what gets communicated.

The practical question is who performs the classification and against what definition. Where severity is assigned at the provider's discretion without published criteria, the same event can be handled very differently depending on who is on shift. Published definitions tied to observable conditions, such as loss of redundancy versus loss of supply, remove that variability.

Worth checking specifically: does loss of redundancy count as an incident at all? A facility running on a single path after a failure is operating without protection even though every tenant is still up. Agreements differ on whether that triggers notification, and the difference tells you something about how the provider thinks.

What an escalation matrix should actually specify

A credible matrix is concrete on four points.

Who is contacted at each tier, by role. Named individuals go stale; roles do not. The matrix should reach a duty manager and then an executive, not stop at the operations floor.

The time window at each tier. Escalation that depends on a technician deciding to escalate will be inconsistent. Time-based automatic escalation is what makes the matrix function at three in the morning.

Who the provider contacts on the tenant side. This runs in both directions and is the half tenants most often neglect. If your own contact list is two people who have left the company, the provider's process cannot help you. Review it at least annually.

The channel, and its fallback. Email is the common default and is also the channel most likely to be delayed or filtered during a major event. A second channel matters.

Notification timing is the commitment that matters

The important distinction is what the clock runs from. A commitment to notify within thirty minutes of detection is meaningful. A commitment to notify within thirty minutes of determining the cause is not a timing commitment at all, because diagnosis has no fixed duration.

Good practice is an early notification that says what is known and what is not, followed by updates at a stated interval until resolution. Tenants generally prefer a sparse update every thirty minutes to silence followed by a complete explanation two hours later. Silence forces people to assume the worst and act on it.

Planned work deserves the same scrutiny

Not every service-affecting event is a failure. Maintenance, upgrades and testing all carry risk, and the notice a tenant receives determines whether they can prepare.

Ask how much notice is given for planned work, whether tenants can object or request rescheduling, and what happens when planned work overruns its window. The discipline around this is a reasonable proxy for operational maturity generally, and it is covered in our guide to change management and methods of procedure in a live data centre.

The post-incident report

Ask to see a redacted example before signing. A provider who can produce one is telling you the process exists; a provider who cannot is telling you something as well.

A useful report distinguishes the immediate cause from the contributing factors. "A breaker tripped" is an immediate cause. Why the breaker was loaded to the point of tripping, why the condition was not detected earlier, and why the transfer did not occur as designed are the contributing factors, and they are where the learning sits.

It should also state what changes as a result, with an owner and a date. Reports that end at explanation without commitment tend to describe the same failure again a year later.

Why a provider may tell you less than you want

During a multi-tenant incident there is a real tension between speed and accuracy, and it is worth understanding rather than resenting.

Early information is frequently wrong. A provider who broadcasts an initial diagnosis that later proves incorrect has made the situation worse for every tenant who acted on it. That is a legitimate reason for caution in the first minutes.

There is also a confidentiality dimension. A provider generally cannot tell you which other tenants are affected, and in a shared facility the scope of impact is often the thing you most want to know.

What this means practically is that the commitment worth negotiating is not detail, it is cadence. A provider who says "we have a confirmed power event affecting Hall 2, cause not yet established, next update in thirty minutes" has given you everything you need to begin your own response, without speculating. Insisting on root cause in the first notification tends to produce slower notifications rather than better ones.

Status pages are not notification

Most providers maintain a status page. It is a useful artefact and a poor primary channel, because it requires the tenant to already suspect a problem and go looking.

Treat it as a supplement to direct contact rather than a substitute. Two questions are worth asking: is the status page updated by the same process that issues direct notifications, or separately by a different team, and does it carry a subscription mechanism so updates are pushed rather than polled. Pages maintained independently of the incident process tend to lag the incident, sometimes considerably.

Test the process before you need it

An escalation path that has never been exercised is a document rather than a capability. Two low-cost tests are available to any tenant.

The first is simply to raise a low-severity ticket outside business hours and observe what happens. Response time, who responds, and whether the handling matches what the agreement describes are all visible from a routine request, and none of it requires an incident.

The second is to ask, during onboarding, for a walkthrough of what would happen in a defined scenario: loss of one power path at two in the morning on a public holiday. A provider with a working process will answer specifically. A provider without one will answer in generalities, and that distinction is the information you were looking for.

Both tests are more informative than any clause, and both are easier to run at the start of a relationship than halfway through one.

Where this sits alongside the SLA

None of this replaces the service level agreement. It complements it. The SLA sets the remedy; the incident process determines your ability to respond while the event is live. Our colocation SLA guide covers the metrics and remedies side of that relationship.

It also helps to understand the failure modes the process exists to handle. Our overview of data centre power resilience sets out how grid failures, transfer switching and redundancy design interact, which is the context most severe incidents arise from.

A short assessment list

• Are severity levels published, with criteria tied to observable conditions?
• Does loss of redundancy trigger notification, or only loss of service?
• Does notification timing run from detection or from diagnosis?
• Is escalation time-based and automatic, or discretionary?
• What is the update interval during an ongoing incident?
• Is there a second communication channel if email fails?
• How much notice is given for planned work, and can it be challenged?
• Can the provider show a redacted post-incident report?
• Is your own contact list current on their side?

These questions are easier to ask during a procurement than during an outage. For the broader set worth settling before signing, see our colocation buyer's checklist.