The server is down, nobody can work, and three people are standing at your desk. What happens in the next thirty minutes decides whether this is an anecdote or an incident: most of the lasting damage in server outages is not done by the fault but by the response, because the panicked half-hour is when data gets overwritten, evidence gets destroyed, and a two-hour problem gets converted into a two-day one. This page is the calm version of that half-hour, written to be read now and skimmed under pressure later.
One instruction before the list: if there is any sign of ransomware (files renamed, a note on screen, staff reporting locked documents), stop reading this page and switch to the incident response plan, because a security incident and a hardware failure need opposite first moves.
Minute 0 to 5: establish what “down” means
“The server is down” arrives as one sentence but describes a dozen different faults, and the first five minutes are for finding out which one you have:
- Is it the server or the path to it? If one person cannot reach it, suspect their machine; if everyone cannot, suspect the server or the network between. A quick check of whether other services (internet, printers, cloud apps) still work separates “server down” from “network down”, which are different emergencies with different fixes.
- Is the machine itself alive? Physically look at it if you can: power lights, error lights, noise. A silent dark box, a box screaming with fan noise, and a box that looks normal are three different diagnoses.
- What changed? The single most diagnostic question in IT. A power blip overnight, an update that ran, a new switch plugged in, building work near the comms cabinet: the answer is very often in the last thing that happened.
Write down what you find with times attached. Two minutes of notes feels bureaucratic now and becomes gold an hour in, both for whoever fixes it and for the insurance or post-incident review later.
Minute 5 to 10: the do-not-touch list
Before anyone does anything heroic, the things that make outages worse, in the order they usually happen:
- Do not repeatedly power-cycle it. One controlled restart is a legitimate step (below). Yanking power repeatedly on a machine with a failing disk or a half-written database is how recoverable faults become data loss.
- Do not let the most confident person in the office start “trying things”. Uncoordinated fixes destroy the evidence of what actually failed and stack new changes on top of the fault. One person leads; everyone else stands down.
- Do not touch the backups yet, except to protect them. Specifically: do not overwrite last night’s good backup with a backup of the current broken state, and if the fault has any whiff of malice, disconnect backup drives from the network rather than plugging more in. Your backup is now the most valuable object in the building; treat it that way.
- Do not announce a fix time you invented. Tell staff “it is down, we are on it, next update at half past” rather than “ten minutes”, because you do not know yet, and credibility spends better than optimism.
Minute 10 to 20: safe triage
With the situation mapped and hands off the dangerous options, the checks that fix a large share of outages without risking anything:
- Power and environment. Tripped breaker, failed power strip, UPS that exhausted its battery and never came back, an aircon failure cooking the cabinet. Environmental causes are common, cheap, and visible from the doorway.
- Network path. Restart the switch between staff and server (a genuinely low-risk restart, unlike the server itself); check cables were not disturbed; confirm whether the server responds on the network even though a service on it does not.
- The one controlled restart. If the machine is unresponsive and the checks above found nothing, a single clean restart (shut down properly if it will take commands, one power-button hold if it will not) is reasonable, once. Watch what it does as it comes up and write it down: error messages on boot are diagnosis, not decoration.
- If it comes back: resist declaring victory. A server that fell over for no visible reason and returned the same way has told you it will do it again. The fault is now scheduled, not solved; the difference is you get to pick the time by investigating properly.
Minute 20 to 30: escalate and communicate
If thirty minutes of safe steps have not restored service, the fault is beyond safe DIY, and the next moves are organisational:
- Call your IT support, with the notes you took: what “down” means, what changed, what you checked, what the restart said. That call, with that information, starts a response-time clock and skips the twenty questions a cold call begins with. If you have no provider, an emergency callout is the route, and the same notes cut its cost.
- Make the failover decision deliberately. If you have tested recovery arrangements (a DR runbook, a cloud replica, documented restore steps), the thirty-minute mark is a sensible trigger to invoke them rather than hoping the fix is close. If your recovery arrangements are untested, the middle of an outage is emphatically not the moment to try them for the first time on your only copy of the data; that call belongs to whoever you escalated to.
- Tell people properly. Staff get the honest status and a workaround if one exists (cloud email usually still works; paper still works). Customers get told before they find out, if the outage touches them. The continuity plan is where these messages were supposed to be pre-written; if they were not, that is the first post-incident action.
After: the questions that stop the sequel
Every outage buys you one free lesson. Once service is back: what actually failed, why did it take as long as it did to notice and fix, when was the backup last tested against exactly this scenario, and what is this server’s replacement age? Ageing on-premise servers are behind a large share of these mornings, and the honest fix is often not a better response but fewer single points of failure: the thirty-minute drill matters most in businesses that still have a box in the corner to lose.
Frequently asked questions
Should I just restart the server?
Once, cleanly, after checking power, environment and network first: yes, that is a legitimate step. Repeated power-cycling of a machine that will not come back is how failing disks lose their data; after one failed restart, stop and escalate.
How do I know if it’s the server or the internet?
Check whether cloud services work from a phone on mobile data versus the office connection, and whether the fault hits everyone or one person. Everyone-and-everything points at the network; one-system-for-everyone points at the server.
What if I see a ransom note or renamed files?
Different emergency: disconnect the machine from the network (pull the cable, do not power it off), protect the backups by keeping them disconnected, and follow the incident response steps. Restarting and restoring over the top are both destructive moves in that scenario.
When should we fail over to backups or DR?
At a pre-agreed trigger, not in the heat of the moment: thirty to sixty minutes of failed safe triage is a common threshold if your recovery is tested. Untested recovery should only be invoked with professional help, because a botched restore risks the last good copy.
How long do server repairs usually take?
Environmental and network causes: minutes. Software faults: hours. Hardware failure with a restore from backup: hours to a day, driven almost entirely by your backup arrangements, which is what the RTO conversation decides in advance.
How do we stop this happening again?
Monitoring that notices before staff do, backups tested against real restore scenarios, a dated replacement plan for ageing hardware, and honestly assessing whether the server should exist at all versus cloud alternatives. All four are standard parts of managed support, which is why managed clients have fewer of these mornings.
The better version of this page is a plan with your name on it
Generic triage is what this page can give you; what your business actually needs is the version with your server, your backups and your escalation numbers filled in, tested once while nothing is wrong. That document is part of what the free IT health check produces, alongside an honest view of whether your server would survive the morning described above. Get in touch while it is still hypothetical.
