Marked Resolved, Still Failing

In 2020, while designing a complaints platform, I wrote a question in my notes:

ML: Recurring => Similar is Solved but similar are still popping up?

The grammar was rough. The problem was exact.

One complaint has been marked solved. Similar complaints keep arriving. Are they new complaints, each deserving a clean record and a fresh resolution time? Or are they evidence that the first complaint was never resolved in the way that mattered?

The platform was never launched, but the question survived it. I have met the same problem since in infrastructure, automated business processes and incident systems. The status changes. The customer does not recover. The ticket closes. The failure returns under a new number.

We use one word, resolved, for two different events. The first happens inside the work system: somebody investigated, applied a change and closed a ticket. The second happens in the world: the affected outcome became correct again and stayed correct.

The first can happen without the second.

Resolution is a claim

A ticket is a record of work. It can tell you who responded, what they changed, when they changed it and why they believed the change was sufficient. These are valuable facts. They are not the same fact as recovery.

A typical incident makes the distinction clear. A payment service begins returning errors. An engineer restarts a dependency. The error rate falls, the endpoint returns successfully and the incident is marked resolved. The operational workflow is complete.

But some payments accepted during the recovery never produce their corresponding orders. The service is healthy. The incident channel is quiet. The customers are still missing what they paid for.

Which statement is wrong?

The restart completed. The endpoint recovered. The alert cleared. The ticket closed. All four statements may be true. The mistake is allowing any of them to speak for the business outcome none of them measured.

Resolved is not a property conferred by a status transition. It is a claim about the world, stored in a ticket. Like every serious claim, it needs evidence at the level where the failure mattered.

Two clocks are running. The upper lane records the team's work. The lower lane records the system's recovery. Closing the first does not stop the second.

The wrong clock stops

Incident metrics inherit the same confusion. Many organisations say they measure mean time to recovery while implementing the clock as time to ticket closure. The clock starts when an alert fires and stops when an operator changes a status. The customer's outcome may not appear anywhere in the calculation.

A metric will train the behaviour used to score it. If the clock stops at closure, fast closure is rewarded. Verification becomes delay. Waiting long enough to learn whether the change held makes the team look slower, while closing immediately makes the dashboard look efficient.

This is how a useful operational measure becomes an administrative performance measure.

There are at least three times inside what teams casually call resolution:

Time to action. How long it took to apply the restart, rollback, configuration change or code fix.

Time to observed recovery. How long it took before the affected outcome worked again.

Time to confidence. How long it took to establish that the recovery was not one lucky request, one cleared queue or one quiet interval.

Collapsing the three produces a precise number with an ambiguous meaning. The number may still improve quarter after quarter while customers repeatedly experience the same failure.

Recurrence has memory

The next incident is where premature resolution becomes expensive.

A failure returns two days later. A new ticket is opened. It receives a new identifier, a new clock and often a new responder. The previous ticket remains resolved because the database state says it is resolved. The two records may be linked in a postmortem if somebody remembers them both.

This reset is convenient for the ticketing system and destructive to understanding. It turns one persistent failure into a sequence of apparently independent successes: incident found, incident resolved; incident found, incident resolved. Every row can look healthy while the series describes a system that has not recovered at all.

Recurrence does not prove that the original cause has returned. Similar symptoms can come from different faults, and certainty would be another way for the record to lie. But recurrence does challenge the previous claim of resolution. At minimum, the old evidence must remain available and the relationship must be considered rather than erased by a new identifier.

A new ticket can either reset the history or deepen it. Only one path preserves what the previous resolution claimed.

Recovery needs the right evidence

The evidence required for closure depends on what failed. A database repair should be checked against the records that were meant to become correct. A broker rebalance should be checked against the distribution and health the operation was meant to produce. A customer-facing incident should be checked at the customer-facing outcome, not only at the service that was restarted.

This does not require pretending that certainty is always available. Some outcomes arrive hours later. Some systems have weak instrumentation. Some incidents end with a reasonable but incomplete belief that the intervention worked. The honest response is not to leave every ticket open forever. It is to record the strength and boundary of the evidence rather than converting uncertainty into a green badge.

"The change was applied" is a valid statement.

"The error rate returned to normal" is a stronger and different statement.

"The affected business outcome recovered and remained healthy" is stronger again.

Problems begin when the first sentence is stored as though it were the third.

Resolution is not the absence of another alert. It is positive evidence that the affected outcome recovered.

Silence after the fix

The quiet period after an intervention is especially easy to misread. No new alert may mean the fault is gone. It may also mean traffic has fallen, the monitoring path is impaired, the affected customer has stopped retrying, or the condition has not yet had another opportunity to occur.

Silence is therefore context, not confirmation. The stronger proof is the return of the behaviour that had failed: another scheduled process completes, another customer receives the expected outcome, another cycle passes through the path that was broken.

The appropriate waiting period differs by system. A checkout path can produce fresh evidence in seconds. A nightly reconciliation process cannot. Declaring both resolved five minutes after a deployment does not make the second system fast; it makes the claim premature.

This is why resolution belongs to the affected obligation rather than to a universal timer. Recovery must be observed on the cadence of the thing that was meant to happen.

Where this leaves us

The question in my 2020 notes was asking whether recurrence should be treated as a new classification problem or as evidence against an old resolution. Six years later, I think the more important part is simpler: a status should never outrank reality.

Ticket systems are useful because work needs ownership, chronology and an end. The mistake is not closing tickets. The mistake is allowing closure to erase the boundary between what the team did and what the system proved.

Resolution is not the end of the work. It is the point at which the claim becomes testable.

A ticket can be closed by a person. A failure is closed only by the system.