Did the last release cause the ticket spike? What GitHub and Zendesk each know, and what neither can tell you

It is Tuesday morning. The release went out Thursday afternoon. On Monday, Zendesk logged 340 tickets against a normal Monday of about 210, and the support lead has already flagged it in the standup channel.

The support lead has a Zendesk view open, filtered to created > 4 days, sorted by requester. It is a wall of one-line subjects: "can't upload," "invoice page blank," "keeps logging me out," "app slow." Some are tagged billing, some bug, most are tagged whatever the triage macro applied. She has read maybe forty of them.

The engineering manager has the GitHub release page open in another tab. Release 4.19.0, cut Thursday at 14:00, 31 merged pull requests, a compare view against 4.18.2 showing 214 changed files. He has read the PR titles. Two of them touched the upload service. One touched session handling. Eleven touched things that could not plausibly be involved.

Both of them are looking at real evidence. Neither can answer the question, which is not "did tickets go up" and not "did we ship a lot." It is: of the extra 130 tickets, how many are about something that changed on Thursday, and which change.

What GitHub shows on its own, and where it stops

GitHub is excellent at what happened to the code. The compare view between two tags is exact: every commit, every file, every line, every author, every review. The release page lists what went in. If you use PR templates and link issues, you get a clean trail from an issue through a branch to a merge to a tag. If deployments are recorded through GitHub, you can see which environment got 4.19.0 and when.

You can go further with the API. Pull request merge times, review latency, files touched per PR, which paths change most often, which PRs reopened issues. Insights will show you commit and contributor activity over time. None of this is a gap in the product.

Where it stops is the boundary of the repository. GitHub knows Thursday's release changed services/upload/chunker.ts. It does not know that on Friday a user in Manchester tried to attach a 40 MB PDF and got a spinner that never resolved, then wrote in to support about it. That event never touched the repository. There is no field in GitHub where it could live.

The nearest thing GitHub has is a linked issue, and linked issues are written by engineers, after triage, for the small subset of reports that make it that far. Two hundred tickets do not become two hundred issues. They become three issues and a lot of unwritten context.

What Zendesk shows on its own, and where it stops

Zendesk is excellent at what customers said and what happened to their request. Ticket volume by day, by group, by tag, by form, by channel. First reply time, resolution time, reopens, satisfaction. Explore will chart Monday's 340 against the trailing average and split it by brand or by product field. The search is good, and if your triage discipline is good, the tags carry real signal.

You can also see the shape of a spike clearly: which hour it started, which channel it came through, whether it was concentrated in one customer segment.

Where it stops is the boundary of the conversation. Zendesk knows a customer wrote "upload just spins forever since last week." It does not know that a chunk size constant changed from 5 MB to 8 MB in a pull request merged Thursday at 13:40, and it has no way to find out. The ticket does not contain a commit SHA. It contains a sentence a person typed while frustrated, plus whatever the agent added.

Even with the GitHub app installed in Zendesk, which is a genuinely useful integration, what you get is the ability to create or link a GitHub issue from a ticket and see its status. That is a per-ticket workflow for tickets somebody already decided were bugs. It is not a population-level answer about 340 tickets, and it was never trying to be.

Why the gap is structural

Look at what the two halves of the evidence actually are.

There is no column in either system that points at the other. The release does not carry a list of tickets it caused, because the causation is discovered afterwards by a human reading. The ticket does not carry a release, because the customer does not know your version numbers and would not mention them if they did.

This matters for tool choice. Automation platforms like Zapier and Make are trigger based and very good at it: a ticket is created, so do something; a release publishes, so post to Slack. They move records forward from the moment an event fires. But "did last Thursday's release cause Monday's spike" is a question about a population of things that already happened, sitting still, needing to be read. There is no trigger to hang it on, because the event you care about is the pattern across 340 tickets, not any one of them arriving.

BI tools have the opposite constraint and are excellent within it. Power BI Copilot and Looker Conversational Analytics both let you ask questions in plain language and both answer well, over databases and modelled sources. Load your Zendesk ticket table and your GitHub commit table into a warehouse and either will chart volume against release dates and give you a real correlation. What they cannot do is read the body of ticket #48213 and judge that "the page where I pay you is white" is about the billing refactor. That is not a query. Free text is not a dimension you can group by, and the judgement is a reading task, not an aggregation.

So the gap is not a missing report. Both products would have to become something other than what they are to close it.

What the join actually requires

Two things, and only one of them is mechanical.

The mechanical half: time and surface. The key that connects the sides is the release timestamp plus the code paths it touched, mapped against ticket creation time and the product area a ticket is about. If 4.19.0 deployed Thursday 14:00 and touched upload, billing, and session code, then the candidate set is tickets created after Thursday 14:00 that concern upload, billing, or sessions. That narrowing is arithmetic. Anyone can do it.

The judgement half: what the ticket is about. This is where matching fails. "Can't upload" is easy. "It just hangs when I try to send the file over" is the same bug in different words. "The attach button is greyed out" is probably a permissions question, not the chunker. "Page is white after I click pay" is the billing change; "why was I charged twice" is not, it is a dunning question that arrives every Monday regardless. And a real share of any spike is unrelated: a marketing email went out Sunday night, an enterprise account onboarded 200 users, a public holiday shifted volume.

The output you want is not a correlation coefficient. It is a count with a reason attached: 130 extra tickets, of which 61 describe upload failures beginning Thursday evening, 12 describe a blank billing page, 8 mention unexpected logouts, and 49 look like ordinary Monday volume with no relationship to the release. Then, for each cluster, the specific pull request that plausibly explains it, so an engineer can go look.

Getting there means reading the tickets. Not all of them, but the ones in the candidate window, individually, with the diff in view. That is a person-day of work done properly, which is why it usually gets done as a guess in a standup instead.

How you would answer it with Skopx

Skopx connects to nearly 1,000 SaaS tools and to databases, and you ask it questions in chat. Both GitHub and Zendesk are in that set, so both halves of the evidence are readable in one place: the diff as a record, the ticket body as a sentence.

The sentence someone would actually type:

Release 4.19.0 went out Thursday 14:00. Monday's Zendesk volume was 340 against a normal 210. Pull the tickets created since Thursday 14:00, read them, and tell me which ones describe something that could have been caused by what changed in 4.19.0. Group them by what broke, and for each group point at the pull requests that touched that area. Tell me separately how many look unrelated.

What comes back is grouped counts with linked ticket IDs and linked PRs, and citations on every claim so the engineering manager can click into ticket #48213 and the commit next to it and check whether the read was fair. Some of it will be wrong. The citations are the point: you audit the reasoning rather than trusting the number.

Once you have run that twice, you will not want to type it a third time. Describing it in a sentence gives you a standing console over the same join, which is what Internal Apps does: a release picker at the top, and under it the ticket clusters for the window after that release, each cluster showing volume against the same window for the previous release, the representative ticket bodies, and the pull requests touching the relevant paths. Support opens it on Monday. Engineering opens it after every cut. It reads from both systems live, and the only thing anyone can change from it is a button that posts the summary as a comment on the release, with a confirmation before it goes.

Honest limits

This does not prove causation. It produces a defensible read of what customers described in a window, next to what changed. A cluster of upload complaints after an upload change is strong evidence and still not proof, and you will occasionally get a coincidence that looks convincing.

It does not read every ticket in an unbounded way. You scope it: a window, a set of product areas, a volume that fits in a run. Ask it to read 40,000 tickets and you will pay for tokens and wait, and the answer will not be better than a well scoped one.

It stores nothing. There is no ticket created, no field written back to Zendesk, no issue opened in GitHub, no record of the analysis kept anywhere except the chat and the console you can re-run. It does not watch for spikes and alert you, it does not run on a schedule, and there is no public link to hand a customer. You ask, or you open the console, and it reads at that moment. The one write is the button, and the button waits for a click and a confirmation.

It also depends on your data being legible. If tickets are untagged and every subject line is "help," the read gets harder, though free text is exactly the material this handles best. If your releases are continuous with no tags and no recorded deploy times, there is no window to draw, and you should fix that first for reasons that have nothing to do with support.

Team is $16 per seat per month with 2.3 million AI tokens included. Solo is $5. SOC 2 controls are in place.