The Invisible Failure
Spent January scraping job postings.
Not for jobs — for signals. I was building a market research tool, pulling hiring trends across industries and tech companies. You can see a lot from what a company chooses to hire for. One cluster kept appearing in support roles: "ticket management", "queue health", "SLA tracking". Not unusual. But the volume was odd. Teams were hiring people to watch queues that should have been watched by systems.
So I went deeper — into support ops forums, Zendesk communities, Reddit threads where ops managers talk honestly about what breaks. Those threads are specific in the way that real frustration is specific. The number that kept surfacing wasn't a failure rate or a resolution time. It was a count of tickets nobody knew existed.
847 was one number. Another team found 300. Someone else ran a manual audit for the first time in two years and found a category of tickets that hadn't had a single reply in months. Not because they were hard. Because nobody knew they were there.
That pattern kept repeating. And the logical response to a repeating pattern is to build something.
I built an audit. It connects to Zendesk, identifies tickets that are aged, unassigned, buried in the wrong views, or sitting in inboxes that stopped being monitored. It produces a ranked list: here's what's buried, here's how long it's been there, here's the exposure. One report. A few hours of work.
The insight wasn't the audit. That part is simple — a few API calls, some sorting logic, a clean output. The insight was what the audit revealed about how these systems fail.
Support platforms don't fail loudly. There's no error. No alert. No red light on the dashboard. Tickets don't disappear — they stay in the database, timestamped, with every status change logged. The failure is invisible not because the data is missing but because nobody has designed a view that asks the right question.
Observable failure has a specific meaning in software: a system fails in a way you can detect. The opposite — unobservable failure — is the dangerous kind. The process is running, the metrics look normal, and what's actually broken is invisible until a customer escalates or an audit surfaces it months later.
Most support teams are running in that second mode. Not because they're negligent. Because the platform defaults to individual ticket views, not queue health views. Because SLA clocks measure response time on open tickets, not the ones that slipped out of any active view entirely. The instrumentation exists — it just isn't pointed at the right question.
The same pattern shows up in software development — bugs that only manifest under conditions nobody thought to monitor for. In project management — work that stalls in a state that looks like "in progress" but has been blocked for weeks. In business — customers who churned without a single complaint, because nobody designed a signal to catch silent attrition.
Visible failure is a design choice. Someone decided to measure this thing, build an alert for it, surface it as a number somewhere. Invisible failure is also a design choice — usually made by not making a choice at all.
The teams that catch buried tickets before a customer escalates aren't more attentive. They just added visibility where the platform didn't provide it.
That's the whole thing. Not a technology problem. A question-design problem: what am I not looking at that I should be looking at?
I built one answer to that question for one specific system — the Buried Ticket Audit. But the question applies everywhere.