By Yair Knijn · September 15, 2025

The same outage every Monday: when you close incidents but never open a problem

The IT operations manager who runs a desk on mean-time-to-resolve is measuring how fast his team mops the floor, not whether anyone has found the leak. Every Monday the same authentication service falls over after the weekend maintenance window. A tech restarts it, closes the ticket in eleven minutes, and the dashboard stays green. The wrong assumption baked into that workflow is that a closed incident is a solved one.

It isn't. The service is restored and the cause is still sitting there, waiting for next Monday. You are paying a salaried engineer to re-fix the same fault on a weekly subscription, and your reporting is built to hide that you're doing it.

Incident vs problem: the ITIL distinction your desk collapses

ITIL 4 draws a line your queue probably erases. An incident is an unplanned interruption you resolve by restoring service. A problem is the cause, or potential cause, of one or more incidents, and the root cause may not be known when it's first logged. Two practices, two goals: incident management restores service fast, problem management removes the reason you keep needing to. When a desk only runs the first one, recurrence is structurally invisible because each ticket opens and closes inside its own little world.

The tell is simple. If you resolve the same symptom twelve times and never once create a record linking those twelve together, you don't have problem management. You have a fast incident desk that resets the same defect on a loop.

Why fast MTTR can hide a problem you're paying for repeatedly

MTTR rewards the restart. An eleven-minute fix twelve times a quarter reads as an elite responsiveness number on any report a director sees, and nobody flags it because each instance was, on its own terms, a success. The metric is doing exactly what you asked. The trouble is what you asked for.

Run the arithmetic the dashboard won't. Twelve recurrences a quarter, an engineer pulled off planned work each time, plus the users who waited out the outage before the restart landed. That's a standing tax you've chosen to pay forever instead of funding one root-cause investigation once. Healthy MTTR and a recurring fault aren't in tension; a desk optimized purely for speed produces both and calls it a good month.

Known errors and workarounds: the record that should have existed

ITIL has a specific artifact for this and your desk skipped it. Once a problem's root cause is identified and an interim fix agreed, it becomes a known error with a documented workaround, recorded in a known error database. That record turns a guessing game into a controlled one: the next tech applies the agreed workaround in seconds and knows a permanent fix is owed and tracked.

• The recurring symptom is captured as a problem, not just a string of unrelated incidents.
• The investigated cause and its interim workaround are written down where the next person finds them.
• A permanent fix is assigned to an owner with a due date, instead of evaporating after the restart.

Promoting recurring incidents into problems before they recur again

The fix is a rule, not a heroics campaign. Pick a threshold the desk can see and enforce it: the same root cause across three incidents in a rolling window automatically opens a problem record, and that record stays open until a permanent change ships. The job stops being faster restarts and becomes fewer restarts needed. A manager who only counts closures never sets that threshold, because his instrument can't see the pattern that should trip it.

That visibility is a tooling decision. An operations workspace that links recurring incidents by root cause, surfaces the repeat count instead of burying it, and lets you promote a cluster into a tracked problem with an owner and a workaround of record is what stops you paying for the same Monday twice. See how OpsDesk handles the incident-to-problem lifecycle, so the recurrence shows up on the report before it shows up on the calendar.