At two in the morning your booking system stops taking payments. Somebody notices at seven, when the first complaint arrives. By nine you have found a phone number, left a message, and sent an email to an address that was set up three years ago.
The support gets sorted eventually. What made the night expensive was not the fault. It was that nobody had ever agreed what happens when there is one.
Most maintenance contracts describe what work gets done: updates, backups, patches, monitoring. Our guides on website maintenance and app maintenance cover that scope and what it costs. This article is about the other half, which is frequently absent from the same agreement: what happens when something breaks unexpectedly, and who does what.
The four questions to settle before you need them
If you take nothing else from this article, settle these four with your supplier while everything is working.
Who, on what channel, in what hours? Not a company name. A route that reaches a person, and the hours during which that route is actually staffed. A surprising number of businesses discover during their first serious incident that the only real path to their supplier is one individual's mobile number, and that individual is on a flight.
What is committed, at what severity? A response time attached to each severity level, in writing. If the honest answer is that nothing is committed outside working hours, that is a legitimate arrangement and you should know you are in it rather than assume otherwise.
Who has the access needed to fix it? This one catches people. If the only person with production credentials is on leave, the response time in your contract is irrelevant. Ask how many people on their side can actually act, and make sure the answer is more than one.
What happens if we cannot reach you? The escalation path, with names and wait times.
None of these requires negotiation or additional spend to establish. They are questions with answers that either exist or do not, and finding out which is the entire point. A supplier who cannot answer all four in an email has told you the shape of your next incident.
Severity, agreed in advance
Without an agreed way to say how bad something is, every report you make is urgent to you and routine to them, and you end up negotiating priority during the incident itself. That is the worst possible time.
The useful framing comes from how incidents get prioritised in public sector guidance. US federal incident handling guidance recommends prioritising by the functional impact on business operations, the impact on information, and how recoverable the situation is [1].
Translated for a business, that means four questions. What has actually stopped working? How many customers or staff are affected? Is money or data at risk? And is it getting worse?
Notice that none of those asks about the technical cause. Severity is about business impact, and defining it that way avoids the conversation where a supplier explains that the underlying issue is minor while your customers cannot pay you.
Three or four levels is enough:
The service is down, or money cannot be taken. Nothing else matters until this is resolved.
A major function is broken with no workaround. People cannot do their jobs, but the business is still trading.
Something is broken and there is a workaround. Annoying, costly in aggregate, survivable for a day.
Everything else. Handled in the normal queue.
Resist adding more levels. Every additional boundary is something somebody will argue about at exactly the wrong moment.
Agree also that the initial classification is yours. A supplier deciding that your incident is not urgent is an argument you cannot afford to be having while it is happening, and genuine misclassification can be corrected calmly afterwards.
Response is not resolution
These get conflated in contracts and they are different commitments.
Response means somebody has acknowledged it and started work. Resolution means it is fixed.
Suppliers commit to response times because they control them. They are cautious about resolution times because nobody can know in advance how difficult a fault will be. That caution is fair, and you should not read it as evasion.
What you can reasonably ask for instead is updates at agreed intervals until it is resolved. Every thirty minutes on a severe incident, hourly on a moderate one. That is the thing that actually reduces the pain of an outage, because most of the distress in an incident comes from not knowing what is happening.
Be prepared for an honest answer about what your current arrangement includes. For a great many businesses the truthful response is that nothing is committed outside working hours, because nothing was ever paid for.
Work out what an hour costs
This single number decides most of the questions in this article, and almost nobody calculates it.
Take the revenue that flows through the affected system in a typical period and divide it down to an hourly figure. Add the cost of staff who cannot work. Add anything you owe customers when you fail them.
It will be rough. Rough is enough, because you are choosing between paying for standby cover and not, and those two options are usually far apart in cost.
For a business whose systems are used only in office hours, paying for overnight cover is generally waste. For anything taking orders around the clock, the arithmetic flips fast. The mistake is not choosing wrong. It is never doing the calculation and then being surprised by both the outage and the invoice.
Out-of-hours cover costs more because it requires somebody available who would otherwise be asleep. When buying it, ask specifically whether you are getting a person on standby or best-effort availability. The two read almost identically in a contract and behave completely differently at 2am on a public holiday.
The escalation path
The common failure is not a supplier refusing to help. It is nobody answering and no agreed next step.
So write the sequence down: the support channel, then a named account manager, then a named director, with a wait time at each step. Thirty minutes at the first level for a severe incident, two hours for a moderate one.
Agree the wait times in advance rather than judging in the moment, because judgement under pressure reliably errs toward waiting too long. When the trigger is defined, escalating becomes a procedure you are following rather than a decision you have to justify to somebody who might be asleep.
For severe incidents, get a phone number and confirm it is answered by a person rather than a mailbox. Email and ticket systems are right for most requests and are checked on a schedule. An incident costing money every hour needs a channel that interrupts somebody.
The access problem nobody checks
A response time is worthless if the person who responds cannot actually fix anything.
This is the most common hidden failure in support arrangements and it takes one question to surface: how many people on your supplier's side hold the credentials needed to act on a production problem? If the answer is one, your effective response time is that individual's availability, whatever the contract says. Holidays, illness and resignations all become your outage.
The mirror of that question applies to you. Who on your side can authorise emergency spending at 2am? If the only person who can approve an unplanned invoice is unreachable overnight, a supplier willing to work may end up waiting for permission. Agree a threshold in advance, something like: for a severe incident, work proceeds and the commercial conversation happens afterwards.
There is a third version worth checking, which is access to the accounts themselves. If the hosting account, the domain registrar or the payment gateway is only reachable through credentials your supplier holds, then an incident where you and that supplier are out of contact becomes unrecoverable rather than merely slow. Our guide on the accounts your business must own covers what should sit in your name and why.
All three are questions with concrete answers, and all three are much cheaper to ask on a quiet Tuesday than to discover at two in the morning.
Test it, because nobody does
Once a quarter, use the emergency route outside normal hours with a genuine but low-severity issue. Tell the supplier afterwards that it was a test.
You will find out whether the number still works, whether the named contact still works there, whether the inbox is monitored, and how long the whole thing actually takes. Every one of those has a way of degrading quietly between incidents, and finding out during a real one is the expensive version.
This is the single cheapest useful thing in this article and virtually nobody does it.
Your side of the arrangement
Half of a good incident response is internal, and it is entirely within your control.
Write one page covering who to contact, on which number, in which hours, who to escalate to and after how long, and what your team should gather before calling.
Store it somewhere that does not depend on the system being up. That detail sounds obvious and is learned the hard way with impressive regularity: the incident procedure lives on the intranet, and the intranet is what is down.
On what to gather first: what is broken in plain terms, when it started, whether anything changed recently, how many people are affected, what error appears and where, and whether it affects everyone or only some users. Five minutes assembling that saves considerably more, because it lets a supplier start working rather than start questioning.
That "whether anything changed recently" item is worth emphasising. Recent change is the first thing any competent responder checks, because it is the most common cause by a wide margin: a deployment, a configuration change, a certificate expiring, a third-party update. Keeping even a simple record of what changed and when pays for itself the first time you have an incident.
Find out before your customers do
Basic uptime monitoring that checks your site every few minutes and alerts somebody costs very little and is among the highest-value things you can add.
Being told by a customer that your site is down means it has probably been down for a while. The first question any incident review asks is how long it took anybody to notice, and "a customer told us" is a poor answer.
One refinement matters more than the rest: monitor the transaction, not just the page. A homepage returning a healthy response while checkout silently fails is the most common blind spot in basic monitoring. Watch the actual business action, a completed test order or a successful login, because a server answering tells you remarkably little about whether the business is working.
Backups you have never restored
A backup that has never been restored is an untested assumption sitting in a file.
Ask three questions: when was a restore last actually performed, how long did it take, and how much data would have been lost? If nobody can answer, that is your finding, and it is far better found now.
Note also the difference between a backup and a recovery plan. A backup is a copy of data. A recovery plan is a documented sequence somebody can follow to get a working system back: where things are, in what order they start, who holds which credentials. Most businesses have the first and not the second, which is why recovery so often takes days rather than hours. Our guide on business continuity covers that planning properly.
Afterwards
Hold a short review once things are stable. Half an hour, half a page.
What happened, why did it take as long as it did to notice and to fix, and what would prevent a repeat. Keep it about the system rather than about the person, because a review that assigns blame reliably produces less information the next time, and less information is the opposite of what you want.
The output should be two or three specific changes with owners. Monitoring on the thing that failed silently. A documented step that was missing. A dependency that needs upgrading. If a review produces no changes at all, either the incident was genuinely unpreventable or nobody asked hard enough questions, and the second is much more likely.
If it is a hosted product
You still need the answers even though you cannot change most of them.
What does the provider commit to? Where is their status page, found now rather than during an outage? How do you raise something urgent? And what does your business do while they fix it?
That last question is the one worth thinking about in advance, because it is the only part you control. Knowing that the platform itself is down is genuinely useful information, since it tells you to communicate with customers rather than keep diagnosing.
Where two suppliers each point at the other, our guide on suppliers blaming each other covers how to break that standoff with evidence.
What to do this week
Write the page. Who to call, on what number, in what hours, who to escalate to and after how long, what to gather first. Store it somewhere independent of the systems it covers.
Twenty minutes, no cost, and it is the highest-return preparation available to most businesses.
If you want help beyond that, defining severity levels, response expectations, an escalation path and a one-page procedure for your team starts from around AED 1,500 with us. Reviewing an arrangement you already have, including actually testing whether the routes work, sits in the same range. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- NIST Special Publication 800-61, incident response recommendations and considerations for cybersecurity risk management
- NIST, computer security incident handling guidance
- SKIMBOX, website maintenance and AMC in Dubai
- SKIMBOX, mobile app maintenance cost in Dubai
- SKIMBOX, business continuity and disaster recovery in the UAE
- SKIMBOX, when two suppliers blame each other
NIST guidance addresses cybersecurity incident response for US federal agencies. It is cited here for its prioritisation approach, which adapts well to ordinary operational incidents, rather than as a standard binding on private businesses in the UAE.
