Two Tickets For One Outage Is Two Stories

When a second ticket turns up for a problem you are already investigating, the most valuable thing you can do is merge it into the first one quickly, move its evidence across, and close it with a pointer. Not because tidiness matters, but because two open tickets for one outage become two theories, two owners and two sets of evidence that never meet. The fault does not care how many tickets describe it. The people trying to fix it do, because attention is the scarce resource, and a duplicate spends it twice.

A duplicate is rarely careless

It is tempting to treat duplicates as an admin annoyance caused by someone who did not search first. In my experience that is almost never what happened. Someone saw the symptom from a different angle, in a different place, at a different time, and reasonably wrote down what they saw. A person loading pages in one environment and a person watching traffic at the edge of the network may be describing exactly the same fault in completely different vocabulary. Neither is wrong, and neither can easily tell they are looking at the same thing.

That is the reason the duplicate is valuable. A second report of the same symptom is a free, independent data point. It might carry a timestamp the first report lacked, a different environment, a new reproduction path, or confirmation that the problem is not confined to where you assumed it was. Closing it unread throws that away. Leaving it open throws away something subtler: the discipline of a single narrative.

What goes wrong when both stay open

The failure I keep seeing is gradual. Both tickets move to in progress, because both have someone reasonable attached to them. Each owner starts forming a view. The views are built from different evidence, so they drift. One person is convinced it is a network path problem. The other has noticed something on the application side and is quietly pursuing that. Neither conclusion is unreasonable, and neither person knows the other has one.

Then the updates start. Anyone who needs a status, whether a customer, a manager or a colleague waiting on a fix, now has to decide which ticket to believe. If the two disagree, the reader assumes the team does not know what is happening. If they agree, they have read the same thing twice and learned nothing new. Either way, the person asking for an answer has been handed a reconciliation job, and reconciliation is exactly what a ticket is supposed to save them from.

There is a cost on the engineering side too. A diagnostic run for one ticket is often repeated for the other, because neither owner can see the first result. Worse, a change made to test a theory on one ticket can quietly disturb the evidence the other owner is collecting. You end up with two people running experiments on the same system without knowing it, and any result you get is hard to trust.

The merge is the real work

Closing the duplicate is the easy part. The part that actually helps is the transfer. Copy across whatever the second report knew that the first did not: the times, the environments, the reproduction steps, the surprising detail. Then write down, on the surviving ticket, what that new information changes or confirms about the current theory. If it changes nothing, say so, because that is also a finding.

On the duplicate itself, leave a short note naming the primary and its owner, and tell the person who raised it that their report mattered and where to follow along. This sounds like politeness, and it is, but it is also operational. People who feel their report vanished stop reporting, and the next independent data point never arrives. Someone who sees their evidence land in the right place keeps sending more.

It also helps to be clear about who owns the incident, as distinct from who owns the ticket. One ticket can have several people working on pieces of it. What it should have is one person responsible for the story: what we know, what we do not, what we are doing next, and when we will say more. That person is the one who decides whether a new report is a duplicate, a related fault, or something separate that merely looks similar.

When not to merge

I would not merge on symptom alone. The same visible error can come from several unrelated faults, and folding two different problems into one ticket is its own mistake, because you will end up declaring victory when the first is fixed while the second carries on. The test I use is whether the two reports could plausibly share a single cause. If the evidence is compatible with one cause, merge, and keep the option of splitting later. If the evidence points to different mechanisms, keep them apart and cross-link them so each owner can see the other.

That cross-link is worth more than people give it credit for. Even when two tickets stay separate, a visible line between them says: someone else is looking at something nearby, so check before you run that experiment.

Why this matters beyond tooling

This is not really about a ticketing system. It is about how a group of people arrives at a shared understanding under pressure. Pressure pushes everyone toward action, and action pushes people to work on whatever is in front of them. A duplicate ticket is a small structural invitation for two people to work in parallel without coordinating, and the incident is the worst possible time to find out how uncoordinated you are.

The commercial angle is blunt. Every hour spent on duplicated diagnosis is an hour the affected users stay affected, and an hour of mixed messaging is an hour of lost confidence from whoever is waiting. A few minutes spent merging, summarising and naming one owner is about the cheapest reliability improvement available, and it needs no new tooling at all.

So the next time a second report lands for something you are already chasing, resist the urge to leave it alone because both are being handled. Read it for what it knows, move that knowledge to one place, and give the incident a single voice. Two tickets for one outage is two stories, and the people waiting on a fix deserve one.