Did the Last Release Cause the Ticket Spike?

On Thursday the support lead posts in #support-leads: "We're at 340 tickets this week, normal is 210. Something's wrong." On Friday the engineering manager looks at the deploy log and sees that four things went out on Monday and Tuesday: a checkout refactor, a change to how session tokens expire, a new onboarding email sequence, and a dependency bump on the PDF export library. All four passed CI. None triggered an alert. Error rates are flat. The status page is green.

So the question sits there, unanswered, for the rest of the week. Did the release cause the spike? And if it did, which part of it?

Nobody can say. Not because the information is missing, but because it is spread across two systems that describe reality in incompatible ways. GitHub knows exactly when each thing shipped, down to the second, with the commit message and the PR description and who approved it. Zendesk knows exactly what customers are complaining about, in their own words, in a free text field. The join between those two facts is a human being reading tickets and remembering what shipped, and the only human who can do both is the engineering manager, on a Friday, with 340 tickets to read.

What people do instead

The usual approach is to eyeball it. Someone opens Zendesk, sorts by created date, reads the first thirty tickets from Wednesday, and forms an impression. The impression is usually "a lot of these are about login." Then someone else says the login thing was probably the token expiry change, and that becomes the working theory. The engineer who wrote the token change spends two days looking at it and finds nothing, because the actual cause was the checkout refactor changing a redirect that dumped people back to a login screen mid purchase. The tickets said "login" because that is the screen the customer was looking at when they got stuck. The ticket text was accurate. The interpretation of thirty tickets read in a hurry was not.

The second thing people do is look at engineering metrics. Deployment frequency is up. Change failure rate is zero, because nothing failed in a way that produced an incident. Mean time to restore is not applicable, because nothing was restored. Cycle time looks healthy. Every DORA number says the week went well. Commit and PR metrics tell you what you shipped, and they tell you how efficiently you shipped it. They tell you nothing about what shipping did to the people on the other side.

The third thing people do is look at a ticket volume chart. It goes up. It has always gone up sometimes. A volume chart is good at telling you that something happened and it cannot tell you what.

Why the tools you already pay for cannot close this

Be precise about this, because the tools are not bad and the vendors are not lying.

Your BI stack connects to databases and modelled sources. Looker works over SQL dialects. Metabase ships nineteen official drivers, and every one of them is a database. That is the design, not a flaw: a semantic layer sits on top of structured tables and answers questions about columns. If your Zendesk data syncs into a warehouse, BI will chart ticket count by day, by queue, by priority, by tag, and Power BI Copilot, Looker Conversational Analytics and Tableau Pulse will all let you ask for that chart in a sentence and produce it well.

The constraint is what reaches the warehouse in the first place. The ticket body is a paragraph a customer typed. In most syncs it is left out, truncated, or landed in a column nobody has modelled against, because a semantic layer is built to aggregate values and there is nothing useful it aggregates about a sentence. What you are left with, reliably, are the fields an agent filled in: queue, priority, tag. And grouping by tag is not the same as grouping by what happened, because tags are applied after the fact, inconsistently, from a list written eighteen months ago. The tag login covers the token change, the checkout redirect, and a customer who forgot their password. Once you have grouped by tag, the distinction you needed has already been destroyed.

On the other side, the deploy timestamps are usually not in the warehouse at all. GitHub deployment events and Linear issue completion timestamps are two more sources someone would have to build a pipeline for, and nobody has, because until this Thursday nobody needed them joined to anything. For a company with forty engineers, the honest situation is that these systems have never been in the same place and probably never will be. Building the pipeline costs more than the question is worth, so the question does not get asked.

This is also why BI content covers ticket volume trends endlessly and almost never covers attributing a spike to a specific release. The evidence lives in prose, and the sources BI is pointed at are databases and modelled tables. Internal tools builders do not cover it either, because a CRUD panel needs a table to sit on and this question has no table. It has two timestamps and a pile of English.

What the question actually requires joining

Written out plainly, answering "did the release cause the spike" needs four things brought together:

The third row is the one that breaks everything else. It cannot be selected, filtered or grouped by, because it is not stored anywhere. It has to be read out of sentences a customer wrote. And the fourth row matters more than people expect: a cluster of forty tickets about PDF exports means nothing if you get forty of those every week. It means everything if you normally get three.

Doing it in Skopx

Skopx connects to GitHub and Zendesk the same way it connects to the other nearly 1,000 tools in its catalog, and to your Postgres directly if the ticket data happens to live there too. You do not model anything first. You ask.

The sentence someone would actually type, in chat:

"Compare support tickets from the 4 days after our Monday and Tuesday deploys against the same weekday window for the previous 5 weeks. Group the new tickets by what they describe, based on the ticket body, not the tag. For each group, show me the count, the change against baseline, and which deploy went out closest before the first ticket in that group appeared."

Skopx pulls the GitHub deployment events with their PR titles and bodies, pulls the Zendesk tickets with full descriptions for the current window and the five baseline weeks, reads the descriptions and groups them by what the customer is describing rather than how the ticket was filed, and lines those groups up against the deploy timeline.

What comes back is not "tickets are up 62 percent." Using illustrative numbers, it is something closer to:

• 61 tickets describing being sent back to a sign in screen partway through paying. Baseline for that description: 2 per week. First one appeared 40 minutes after the checkout refactor deployed.
• 44 tickets describing being logged out unexpectedly during a normal session. Baseline: 31 per week. Slight rise, first one appeared 11 hours after the token expiry change, and the wording is materially the same as the ones from three weeks ago.
• 9 tickets describing PDF exports rendering with the wrong fonts. Baseline: 0. First one 6 hours after the dependency bump.
• The rest, roughly the usual mix, at roughly the usual rate.

That answer reframes the week. The token change, the obvious suspect, is close to noise. The checkout refactor, which nobody suspected, produced a cluster that essentially did not exist before. And the PDF thing is small but real and nobody had noticed it at all, because nine tickets across four days never crosses anyone's threshold.

What the console looks like

If this is going to be a recurring question, and after a release it always is, you can ask Skopx to lay the same answer out as a page. Describing the screen in a sentence is enough: "Build me a release impact console: the deploys from the last 14 days in a table with their times, ticket clusters for the window after each one with the baseline comparison, and the tickets themselves in a table I can open." Skopx runs the query against the sources you already connected, measures what actually comes back, and renders accordingly. That is what internal apps do: read from your connected tools and lay out metrics, tables and charts based on the real returned rows, not a schema someone drew in advance.

The page ends up with a small number of metric tiles at the top: tickets in window, tickets above baseline, number of clusters that are new rather than elevated. A bar chart of clusters against their baselines. A line chart of ticket arrival by hour with the deploy times marked. A table of the clusters, and under each one the actual tickets, with the customer's own words visible, because the words are the evidence and hiding them behind a count is how you get back to guessing.

And then a button. One button, next to the cluster you have decided is real, that files a Linear issue with the cluster name, the count, the baseline, the deploy it lines up with, and links to the five most representative tickets. A person clicks it. It asks for confirmation first. It runs that one action in Linear and stops. That is the whole write path, and it should be, because deciding that a cluster is a bug is a judgment call and it belongs to a human.

The honest limits

Correlation in time is not proof. A cluster that starts 40 minutes after a deploy is a strong signal and it is still not a causal claim. Something else may have changed at the same time: a marketing campaign landed, a partner integration broke, a third party had an outage. The console narrows two days of speculation down to one thing worth looking at. It does not replace looking at it.

Grouping by description is a judgment too. Two tickets that a person would file together sometimes land in different groups, and the boundary between "sent back to sign in during checkout" and "logged out unexpectedly" is genuinely fuzzy. Read the tickets under a cluster before you act on the number.

Baselines need enough history to mean something. If your ticket source only holds 30 days, a five week baseline is not available and the comparison gets weak.

And this is retrospective by design. The page keeps nothing of its own: it holds no records, and every time someone opens it, it re-reads GitHub and Zendesk and works out the answer again. It does not sit there watching for the next spike, it does not run on a schedule, and it does not send anyone an alert. Someone opens it after a release, because after a release is when the question exists.

Close

The reason this question goes unanswered is not that it is hard. It is that the evidence for it lives in sentences, and the entire analytics stack is built on columns. Deploy timestamps are structured and support tickets are prose, and the join between them has been left to whoever is willing to spend a Friday reading. Doing it properly takes about a minute of asking, once something can read both sides at the same time.