STSaasTechify/dev
← All posts
Product28 May 2026· 5 min read

Building SLA escalation that doesn't cry wolf

The first version of most SLA escalation systems fires on a single threshold: ticket open for more than X hours, notify someone. It takes about two weeks in production before that notification gets muted, because it fires on tickets that are genuinely fine — waiting on a customer reply, waiting on a part that's already in transit.

What actually works is escalation that accounts for ticket state, not just elapsed time. A ticket sitting in 'pending customer' shouldn't count against the same clock as one sitting untouched in 'open'. Once escalation only fires on tickets where the business is actually the bottleneck, the alert regains trust — and the team stops muting it.

The second lesson: escalate to a person, with context, not to a channel. 'Ticket #4521 breached SLA' in a Slack channel with forty other messages gets ignored. A direct notification naming the specific technician and service center, with the ticket's actual history attached, gets acted on.

We built this as a Vercel cron job checking SLA state every few minutes rather than a long-running worker — simpler to operate, easier to reason about, and it scales fine for the ticket volumes most after-sales platforms actually see.

Building something similar?

Let's talk through the actual problem, not a generic pitch.

Start a conversation