The incidents that were fixed in Slack and never closed in PagerDuty

It is Monday morning and the SRE lead is building the incident review for the week. Two windows are open. On the left, the PagerDuty incidents list filtered to the last seven days: forty-one incidents, each with a status, a service, an assignee, a timestamp for triggered and a timestamp for resolved. On the right, Slack, scrolling back through #incidents and the four channels that spun off it.

The numbers do not agree, and she already knows why before she starts counting. On Wednesday at 02:14 a disk-usage alert fired for the ingestion service. In #incidents, the on-call engineer posted "this is the backfill job again, it clears itself once the batch finishes," and forty minutes later posted "confirmed, back under threshold." The alert in PagerDuty was acknowledged at 02:15 and resolved at 09:40, when he got to his desk. So PagerDuty says that incident took seven and a half hours. The people in the channel know it took forty minutes and that nobody touched anything.

There are maybe eight of these in the week. She cannot tell you which eight without reading every thread. The engineering director wants a mean time to resolve number for the QBR slide, and the honest answer is that the number in PagerDuty is wrong in a specific, patterned way: it measures how long the alert stayed open, and a chunk of the incidents were actually over long before anyone clicked resolve. Some of them were never real incidents at all. The question she needs answered, which is not a question either window can answer, is: which incidents were resolved in chat without the alert being closed, and how long did they actually take?

What PagerDuty shows on its own

PagerDuty is very good at the thing it is for. Every incident has a full timeline: triggered, acknowledged, escalated, reassigned, notes, resolved. It records who was paged, on which escalation policy, how many times the notification retried, and how long each transition took. You can pull the analytics by service, by team, by responder, and get mean time to acknowledge and mean time to resolve out of the box. The API exposes log entries per incident, so the raw material is genuinely there.

Where it stops is precise. PagerDuty knows when the incident record changed state. It does not know when the problem stopped. Those are the same thing only when someone resolves the alert at the moment the problem ends, and in practice nobody does. The engineer at 02:54 has a working system and a sleeping household; clicking resolve is a chore for the morning. PagerDuty records that chore, faithfully, as seven and a half hours of incident.

It also cannot tell you the shape of the resolution. Resolved-by tells you which account clicked the button. It does not tell you whether the fix was a restart, a rollback, a config change, or a decision that the alert was noise and the threshold is wrong. There is a notes field, and some teams use it well, but a note is optional and the honest state of most incident notes on most teams is empty.

What Slack shows on its own

Slack has the part PagerDuty is missing, in the worst possible format for counting.

The channel has the actual account. It has the engineer saying "this is the backfill job again." It has someone else saying "same as last Tuesday." It has the thread where two people argued about whether to page the database team and decided not to. It has the moment where somebody wrote "we're good" and everyone stopped watching. That message is the real resolution timestamp, and it is more accurate than the one in PagerDuty, and it is a sentence in a thread.

Slack search will find you messages. It will not tell you how many incidents this week ended in chat before they ended in PagerDuty, because "ended in chat" is not a field. There is no status on a Slack message. If your PagerDuty and Slack are already connected, the alert posts into the channel and the thread hangs off it, which helps enormously with the join and not at all with the counting: you now have the two halves adjacent to each other and still no way to ask a question across them.

The other limit is that the interesting messages are the informal ones. Nobody writes "RESOLVED: root cause identified as scheduled backfill, no action taken." They write "yeah it's the backfill thing, leave it." Any approach that depends on people writing in a parseable format has already lost, because the whole reason the information is in Slack is that Slack is where people write the way they talk.

Why the gap is structural, not a missing feature

Look at what each half of the evidence actually is.

This is why the join is not a report either vendor forgot to build. PagerDuty would have to decide which Slack message in a thread constitutes a resolution, which is a reading task, not a query. Slack would have to know what an incident is and which of the sixty messages in a channel belong to which one. Neither is being lazy. The two halves are different kinds of object.

It is also why the usual tooling does not close it. Automation platforms like Zapier and Make are trigger based: something happens, then a step runs, then a record moves forward. That is a real and useful shape, and it is the wrong shape here, because the question is about forty-one incidents that already happened and forty-one threads that were already written. There is no trigger for "last week." BI tools sit on the other side of the same gap. Power BI Copilot or Looker's conversational analytics will happily give you MTTR from the PagerDuty incident table, because that table is modelled data. The evidence that contradicts that MTTR is a sentence in a Slack thread, which is not in the warehouse and would not be a column if it were.

What the join actually requires

Two things, and only one of them is mechanical.

The key. Each incident has an ID, and if PagerDuty posts into Slack, that ID appears in the alert message, which anchors the thread. Every reply in the thread inherits it. Where a channel was opened manually and the ID was never posted, you fall back to service name plus a time window, matching messages within the incident's open period in the channel that owns that service. That is fuzzier and worth flagging rather than hiding.

The judgement. Given a thread of fifteen messages, which one, if any, marks the point the problem stopped? "restarting now" is not it. "back under threshold" is. "we're good" is, usually. "should be fine tomorrow" is not. And separately: did anyone actually do something, or did the system recover on its own while people watched? That distinction is the difference between an incident and a bad threshold, and it is only ever visible in the wording. No amount of schema work turns that into a match. Somebody has to read it.

How you would answer this with Skopx

Skopx connects to PagerDuty and Slack among nearly 1,000 integrations, and reads across both in one pass. The sentence someone would actually type is close to how they would ask a colleague:

For every PagerDuty incident in the last 30 days on the platform services, find the Slack thread for it and tell me whether the problem was resolved in chat before the alert was closed. Give me the message that shows it, the real end time, the PagerDuty resolve time, and the gap. Flag the ones where nobody took any action.

What comes back is a table with a row per incident: incident ID, PagerDuty MTTR, chat-derived resolution time, the delta, and the quoted message that supports it, each one linked back to the Slack permalink and the PagerDuty incident so anyone disputing a row can click through and read the thread themselves. The citation matters more than the number. When the director asks why MTTR dropped from six hours to ninety minutes, the answer is not "the tool said so," it is forty-one links.

Ask the same question every Monday and it stops being worth retyping. Describe it once in chat and Skopx builds it into a standing console you can open like any other internal app: the current period's incidents, the two resolution times side by side, sorted by gap so the worst offenders sit at the top, with filters for service and for on-call rota, and a section that groups the no-action-taken incidents by alert rule so the noisy thresholds name themselves. One action button, on a row, for closing a PagerDuty incident that chat says is long over, with a confirmation before it fires and the resolving message shown next to it so you know what you are confirming.

What this does not do

It does not close alerts for you. There is no rule watching your channels, no scheduled sweep, no bot resolving incidents because a message looked conclusive. The only write is a button a person clicks, on a row they are looking at, with a confirmation step. If nobody opens the console, nothing gets closed.

It does not store an incident record of its own. The console reads PagerDuty and Slack live; it is a view, not a second system of record, and if you delete a Slack message the evidence for that row disappears with it.

It will misjudge some threads. Sarcasm, jokes, a "fixed!" that turned out to be premature, an engineer who declared victory and then quietly kept working in a DM: the reading is good, and it is not perfect. Treat the quoted message as the point of the exercise. It is there so a human can overrule the classification in two seconds, and on a review you should expect to overrule a couple.

It cannot see what nobody wrote down. If the real fix happened in a DM, on a call, or in someone's terminal with no comment in the channel, the thread will look like the system recovered on its own, and the console will say so. The account is only ever as complete as the channel.

And it will not reconstruct history you no longer have. Slack retention limits are real, and a workspace on a 90-day plan cannot answer a question about March.