The situation
Month-end review. Ticket volume is up and everyone has a theory: the new pricing page, a noisy customer, "it's just seasonal". The support lead has a chart with a bump in it and no way to say what the bump is made of.
The ticket history already holds the answer. Nobody has time to read four hundred tickets to get it.
What Triagic looked at
The ticket trends checkup runs monthly. It reads your ticket history as a signal about the product, and it works from Triagic's own data even with nothing else connected. This run touched:
- Ticket history: tickets per day over the last 90 days, the most recent 30 against the 30 before, broken down by source (HubSpot, Zendesk, Jira, Slack, forms, manual).
- Sentry: new issues and rate changes around each spike's first ticket.
- GitHub: merges and releases in the window just before it.
It prints what normal looks like first, the typical daily range and the weekday pattern, so a "spike" is measured against a baseline you can see. It also rules out fake spikes: a connector that was down for two days and then backfilled looks like a surge and isn't one.
What it found
One real spike, on the 9th: 61 tickets against a typical day of 18 to 26.
- Composition: 38 of the 61 were one cluster, webhook deliveries failing after signature verification. The rest was normal background.
- Onset: the first ticket of that cluster arrived at 10:12. A cause has to come before that timestamp, not before the peak.
- Candidate cause: a merge at 09:47 that rotated the webhook signing secret's format, and a new Sentry issue first seen at 09:51.
- Resolution: a hotfix at 15:30. The cluster stopped within the hour.
Then the part no chart shows. The same root cause, webhook signature mismatches, accounted for a smaller cluster in each of the two months before. That's one cause, three months running, 74 tickets in total. Fixing it properly costs less than answering it again.
What changed
The monthly report to leadership now says what the volume was made of, with the evidence linked. The recurring webhook cause went to engineering as one issue with three months of tickets behind it, and the next run will say whether it came back.
The procedure is in the open checkup library: Ticket trends and recurring root causes. A narrower one covers webhook failures.