How to Build n8n SLA Breach Alerts That Fire Once

An SLA is a promise with a clock attached, and the clock runs whether anyone's watching it or not. A four-hour response target means nothing if the first time anyone checks is when the customer emails to ask why it's been six. n8n SLA breach alerts put a warning in front of the deadline instead of an apology after it, and they do it without spamming the channel every time the cron fires.

The strongest competitor here gets the warning right and the dedupe wrong. The n8n library's proactive SLA monitoring template computes percent-elapsed and alerts at 75% and 90%, which is the correct shape. But it hard-requires Zendesk and re-fires the same alert on every run. Guides like OneClick's SLA monitoring post and Equanax's RevOps SLA piece describe the alerting but skip the two things that make it usable: a business-hours-aware clock and an alert-state flag.

Those two fixes are the post. And none of it needs a help desk.

Why a breached SLA is usually a silent failure

SLAs don't break loudly. A ticket ages past its target with no error, no exception, no red light. The workflow that was supposed to catch it either never existed or fires so often that the team muted it months ago. Both failure modes end the same way: a customer notices before you do.

Getting this right means two clocks done correctly. The first is the elapsed-time clock, which has to know your support hours or it'll report weekend false alarms. The second is the alert clock, which has to remember what it already said or it'll repeat itself into irrelevance. Tutorials nail the threshold percentages and miss both of these.

What you can automate in SLA monitoring

• A recurring read of every open ticket and its SLA target
• Elapsed-time math that subtracts non-business hours and holidays
• Percent-consumed calculation against each ticket's target duration
• A 75% warning to the assigned agent before the deadline
• A 90% breach alert that escalates and bumps the ticket's priority
• An alert-state flag so each threshold announces exactly once
• A Google Sheets log of every SLA event for the compliance report

Arithmetic and rules, again. The only judgment call is choosing thresholds, and 75/90 is a sane default to start from.

The SLA alert pipeline

Schedule trigger (every 10–15 min)
  → Read open tickets (Sheets / help desk)
  → Code (business-hours elapsed → % consumed)
  → Compare % to alert_state (already warned at this level?)
  → New threshold crossed → alert + update alert_state
  → Sheets log

The alert_state field is the load-bearing piece. It's what makes a workflow that runs 96 times a day send two alerts per ticket instead of ninety.

1. Read the open tickets

A Schedule trigger every 10–15 minutes pulls open tickets. The required fields are small: ticket_id, created_at, sla_target_minutes, priority, and alert_state. On Zendesk that's an API search; on a lean stack it's a Google Sheets read where each open ticket is a row. Either way, the SLA math operates on those five fields and nothing else.

Keep the read scoped to open or pending tickets. Pulling closed tickets through the clock wastes calls and risks alerting on something already resolved.

2. Compute elapsed time the way the team works

A naive clock treats 4 hours as 240 wall-clock minutes. A useful clock knows your team doesn't work nights and weekends. The Code node computes business-hours-elapsed:

const open = new Date($json.created_at);
const now = new Date();
// businessMinutes(): counts only Mon-Fri 09:00-18:00 between two dates
const elapsed = businessMinutes(open, now);
const pct = Math.round((elapsed / $json.sla_target_minutes) * 100);
return [{ json: { ...$json, pct } }];

A ticket opened at 5:55pm Friday should read as 5 minutes elapsed on Monday at 9:05am, not as three days breached. Skip the business-hours adjustment and Monday morning is a wall of false breaches that nobody trusts. The first time that happens, the channel gets muted, and the alerts may as well not exist.

3. Compare against what you already said

Here's the dedupe. Each ticket carries an alert_state — the highest threshold already announced (none, warned, breached). The workflow only alerts when the current percentage crosses a new line:

let next = $json.alert_state;
if ($json.pct >= 90 && $json.alert_state !== "breached") next = "breached";
else if ($json.pct >= 75 && $json.alert_state === "none") next = "warned";
const shouldAlert = next !== $json.alert_state;
return [{ json: { ...$json, next, shouldAlert } }];

A ticket sitting at 82% has already been warned, so the next run that still reads 82% does nothing. When it crosses 90%, shouldAlert flips true once, the alert sends, and alert_state updates to breached. After that it's quiet again. One warning, one breach, per ticket. That's the entire trick the ranking template misses.

4. Alert and write the state back

For tickets where shouldAlert is true, send the alert and immediately write the new alert_state back to the source. Order matters: update the state in the same run, before the next cron tick can re-read the old value. A 75% warning pings the assigned agent. A 90% breach pings the support lead, bumps priority to High, and appends a compliance row.

Implementation patterns worth copying

Pattern A — per-priority SLA targets. A P1 might owe a 1-hour first response, a P3 an 8-hour one. Store sla_target_minutes per ticket from a small priority lookup at creation, so the same percent-consumed math serves every tier without a separate workflow per priority.

Pattern B — the at-risk digest. Real-time alerts catch the ticket about to breach. A once-daily Schedule trigger that lists everything currently between 50% and 90% catches the slow burners early, while there's still time to act before they hit the warning line at all.

n8n nodes you'll use most

Getting started

1. Give every open ticket five fields: created_at, sla_target_minutes, priority, alert_state, ticket_id.
2. Build a Schedule trigger that reads open tickets every 10 minutes.
3. Write the business-hours elapsed function and the percent-consumed calculation.
4. Add the alert-state comparison so only newly crossed thresholds alert.
5. Send the alert, then update alert_state in the same run before anything else.
6. Test with a ticket near each threshold and confirm each alert fires exactly once.
7. Add the daily at-risk digest once the per-ticket alerts are quiet and correct.

For the routing that decides who an alert wakes up, the Customer Health Score & Retention Engine escalates critical accounts to Slack and logs to Sheets, and the Review Response Engine handles the response once an agent picks up the breached ticket.

An SLA alert is only worth building if it lands before the deadline and never repeats itself into noise. Pair this with the tier-climbing logic in How to Build n8n Support Escalation Routing and the classification step in How to Build Support Ticket Triage with n8n and AI for a queue that warns you in time. Mind the business hours. Remember what you said. Let the clock speak once per line it crosses.