The outage happened. The vendor fixed something, people got back to work, everyone breathed out. Three weeks later, same script — different mask, same root cause. It's avoidable, but only if between one fire and the next you find one hour for what corporations call a post-mortem and what SMEs usually don't call anything.
In a big company, a postmortem is a formal procedure with a template, a facilitator and a ticket in Jira. In a 10- or 30-person shop you can get the same result around one table, on one sheet of paper, in one hour. It's not about documentation. It's about making sure the same cable doesn't fall out twice in the same month.
Why this doesn't happen by default in SMEs
In an SME an outage usually ends like this: the IT person (or vendor) says "it was the RAID / the drive / the UPS / the power", closes the ticket and goes back to whatever else was on the list. Nobody asks why nobody noticed the drive had been throwing errors for a week. Nobody checks why the backup that was supposed to save the day turned out to be 11 days old. The conversation stays short, because a long conversation means looking for someone to blame — and everyone wants to avoid that.
That's exactly the trap. If a postmortem is used to assign blame, nobody will tell the truth, and a month from now you'll get the same outage from a different angle. If a postmortem is used to fix the process, people say what they saw — because they know no one is going to fire them for it.
A concrete example — a 12-person design office
We saw this play out at one of our clients. A 12-person electrical design office, a file server sitting in the reception cabinet, Comarch Optima ERP hosted at a partner. Monday morning, nobody can open the drawings — the NAS drive died over the weekend, the RAID controller went with it, and part of the last three days' work is gone.
The IT vendor drove over, replaced the NAS, restored data from a 4-day-old backup. The damage: 22 hours of two designers redrawing schematics, one deadline slipped by a week, the client had a conversation with the owner in a tone the owner would rather not hear again. Material cost — easy to add up — about PLN 6,500. Reputation cost — nobody counted.
Instead of closing the ticket, we ran a one-hour postmortem. It surfaced five things:
- The drive's S.M.A.R.T. alerts had been going to the IT person's inbox — and he'd been on holiday for a week. Nobody else ever saw them.
- The backup ran daily, but it copied to a second partition on the same NAS. When the controller died, so did the backup.
- The offsite copy ran once a week, Friday evening. Between Friday 3 pm and the crash, 4 days of work accumulated that nobody would ever get back.
- Nobody knew the NAS was 6 years old. There was no hardware register with purchase dates.
- The "disaster plan" lived in the IT person's head. With him gone, nobody even knew where the key to the server cabinet was.
None of that required a new budget. It required half a day of housekeeping. A year later, at a similar "pop" (this time an SSD in another server), recovery took 90 minutes from an offsite backup taken the night before. The outage repeated — the consequences didn't.
A one-hour template that actually works
You don't need a tool. A sheet of A4, a pen, one hour, everyone who did anything during the outage (including the vendor, remote is fine). Four blocks:
Timeline — what happened, in order. Not "what someone thinks happened", but what we observed: time of the first user report, time of the first IT reaction, time of the fix going in, time of full recovery. Dry numbers. This block alone usually reveals that "the outage lasted 2 hours" is fiction — users had been down since 8 am, the report went in at 10:15, and IT only found out at 11:30.
Impact — what did it actually take. How many hours of work? How many transactions didn't go through? How many phone calls from clients? Which deadline moved? Without this, nobody will want to spend even PLN 500 on prevention, because "nothing really happened".
Root cause — why, five times in a row. Classic "5 whys". Why did the NAS die? — The controller overheated. — Why did it overheat? — The fan wasn't spinning. — Why not? — It's been clogged with dust for six months. — Why didn't anyone clean it? — Nobody has it on their calendar. — Why? — There's no hardware maintenance schedule at all. Suddenly you know what to actually fix — not the controller, but the missing schedule.
Action items — who, what, by when. Max 5 items. Each with a name and a date. Without this, a postmortem is group therapy, not change.
What separates a postmortem from a witch hunt
One rule worth saying out loud at the start of the meeting: "We assume everyone did the best they could with the information they had at the time." It sounds preachy, but without it nobody will admit that a year ago they muted the NAS alerts because there was too much noise. And that's exactly the piece of information the postmortem exists to surface.
The guilty party doesn't fix the process. The guilty party leaves the company or starts lying. Neither of those helps you. A postmortem looks for a gap in the system, not a gap in the person. People tend to make mistakes in the same places — if your process allows an expensive mistake to slip through without a safety net, that's a process problem.
When to do it, when to skip it
Not every outage deserves an hour-long meeting. A simple rule of thumb: run a postmortem if the outage lasted more than an hour, affected more than one person, or cost money (lost hours, moved deadline, a call from a client). Below that — a line in a simple log (date, what, how long, who fixed it) is enough.
A log covering the last 12 months is surprisingly educational on its own. When you suddenly see that in one year there were seven small outages tied to the same network switch, no vendor needs to tell you it's time to replace it.
What next
A postmortem doesn't cost money. It costs an hour of discipline once a quarter or after a longer outage. It pays for itself with one avoided repeat — and in practice, usually much more.
If nobody in your company sat down after the last outage and asked "why was this even possible?" — that's exactly the place to start. We can help you break down a specific incident and build a template that stays with you afterwards.
An outage isn't a failure. A repeated outage — that's a different story.