Problem management vs incident management: restore first, then remove the cause

The two practices answer different questions, and confusing them is why the same outage keeps happening. An incident asks "is the service working?" and its objective is restoration by any legitimate means, including a restart nobody fully understands. A problem asks "why did it break?" and its objective is removal of the cause so the incident stops recurring. Restarting the service closes the incident. It does not touch the problem.

Nearly every team runs incident management, because incidents are loud. Very few small teams run problem management, because problems are quiet — and the cost of skipping it stays invisible until you add up how much of your incident load is three causes wearing different hats.

Incident management is measured in time: time to acknowledge, time to restore, time degraded. Speed is the entire point, and a workaround is a completely legitimate outcome. If a nightly job wedges and a restart clears it, restart it and close the ticket. Debating root cause while the service is down is a category error.

Problem management is measured in recurrence: how many incidents this cause produced before, and how many it produces after. Its clock runs in weeks, and it is allowed to. The failure mode is running both on one clock — either treating every incident as a root-cause investigation, which wrecks restoration time, or treating every cause as resolved the moment the service came back, which is how a team ends up restarting the same job every night for two years.

A problem with a diagnosed cause and no permanent fix yet becomes a known error: this is what is wrong, this is the workaround, this is why it is not fixed. Teams skip the record because writing it feels like admitting defeat, then pay for it every time the incident recurs and somebody rediscovers the workaround from first principles.

The known error record is the most under-rated artefact in service management, because it is the one thing that makes recurrence cheap. Written once, it converts a forty-minute investigation into a two-minute lookup, and it is the raw material for both a runbook and, later, an automated fix. Keep known errors where support actually looks — attached to the queue, linked from the incidents they explain — not in a wiki nobody opens. A known error that cannot be retrieved is the same as no known error at all.

Two reasons, and neither is laziness. There is no owner: incidents assign themselves to whoever is on call, but a problem belongs to nobody by default, so it belongs to nobody in fact. And there is no time: problem work competes with the roadmap and the incident queue, both of which have people asking about them, while the problem has nobody chasing it.

The structural fix is boring and it works. Give problem work a named owner and a slot in the calendar. One person, one recurring hour, one problem at a time. The instinct to open a record for every recurring cause produces a register of twenty open problems and zero closed ones, which is worse than no practice at all, because it converts a real gap into paperwork proving you know about the gap.

Once a fortnight, take the incident list for the period and group it by cause rather than by symptom, category, or reporter. The grouping is the whole exercise. The moment the list is sorted by cause, the top of it is usually two or three items accounting for a disproportionate share of the queue, and the argument about what to work on evaporates.

Pick the top one. Open a problem with a named owner, a stated hypothesis, and a definition of done expressed as an incident count rather than a task — this cause produces zero incidents over the next month. Then either close it or explicitly park it as a known error with a documented workaround before opening the next one. A team that closes six problems a year has removed six recurring causes. A team with a twenty-item problem register has removed none.

The reactive version starts from incidents that already happened. The proactive version starts from patterns that have not caused an outage yet: the error rate that quietly doubled, the batch job now finishing twelve minutes before its deadline instead of two hours, the certificate renewal that has been manual for three years. This needs no programme — it needs the same fortnightly hour pointed at trends instead of at the incident list, once a quarter.

The honest constraint is sequencing. Proactive work earns its place only after the reactive version is running. A team still drowning in recurring incidents should not be scanning for future ones.

The hard part of the fortnightly review is grouping by cause, because queues are sorted by symptom and one cause arrives phrased six different ways. That is exactly where FlowTux helps: error storms are deduplicated semantically rather than by string match, so one root cause collapses into a single ticket with an occurrence count instead of forty rows, and triage is grounded in the linked codebase and previously resolved tickets, so a new incident tends to arrive already flagged as a repeat of something you have seen. That occurrence count is a recurring-incident review maintained continuously. Once a cause has a documented workaround, categories where the fix is well-trodden and reversible can move from suggest to approve to autonomous, with every action logged on the ticket timeline — problem management paying off as deflection rather than as a register.