The template matters less than the timing. A plain message sent before anyone has to chase you rebuilds more trust than a carefully worded apology sent three days later. These are written to be sent fast, which is why none of them are long.
A good SLA breach notification does four things and stops: names the ticket, states what was missed, gives one honest sentence of status, and commits to a specific next action at a specific time. Everything else — explanation, apology, context — makes it slower to send and harder to read. Seven situations are covered below; the three core ones live in the guide to SLA breaches.
Before the Breach: The At-Risk Warning
Almost nobody writes this one, and it is the most valuable message in the set. Sent while the target is still reachable, it turns a breach from something that happened to the requester into something they were part of.
To the requester, before the deadline
Subject: [TICKET-ID] - heads-up on timing Hi [NAME], We're due to have [TICKET-ID] ([SHORT DESCRIPTION]) resolved by [TARGET TIME]. Right now that looks tight. Where it is: [ONE SENTENCE] If it slips: I'll tell you by [TIME], with a new estimate. No action needed from you. [YOUR NAME]
The last line does the work. Most “heads-up” emails create anxiety because the reader cannot tell whether they are expected to do something. Saying so explicitly removes that.
First Response Breach
Different from a resolution breach and usually more embarrassing: nobody picked the ticket up. Do not explain the queue. The requester does not care how your routing works.
When nobody acknowledged in time
Subject: [TICKET-ID] - sorry for the silence Hi [NAME], You raised [TICKET-ID] at [TIME] and should have heard from us within [TARGET]. You didn't, and that's on us. I have it now. [ONE SENTENCE ON WHAT YOU ARE DOING] Next update from me: [TIME]. [YOUR NAME]
The Second Breach on the Same Ticket
The hardest one to write, because the obvious move — another apology — is the wrong one. A second apology in the same thread reads as a pattern rather than an exception. Replace it with a change of approach.
When you have already missed once
Subject: [TICKET-ID] - changing how we're handling this Hi [NAME], We've now missed two commitments on [TICKET-ID]. Rather than give you a third date on the same basis, here's what changes: What's different: [ESCALATED TO X / VENDOR ENGAGED / REASSIGNED] New commitment: [DATE AND TIME] If that slips, I'll call you rather than email. [YOUR NAME]
When a Vendor Caused It
Resist naming the vendor as the reason. From the requester's side you chose that vendor, so the delay is still yours. State the dependency as fact, not defence.
Third-party dependency
Subject: [TICKET-ID] - update, and where it's stuck Hi [NAME], [TICKET-ID] has missed its [TARGET TIME] target. It's waiting on [HARDWARE / A VENDOR FIX / AN EXTERNAL APPROVAL], raised with them on [DATE], reference [REF]. What I can commit to: I'm chasing daily and will tell you the day it moves. What I can't: a firm resolution date until they give me one. Workaround in the meantime: [WORKAROUND, OR "none, and I'm sorry"] [YOUR NAME]
Splitting “what I can commit to” from “what I can't” is the part worth keeping. Vague reassurance is what destroys credibility on long-running tickets.
When the Delay Was on Their Side
Genuinely difficult. The clock ran because they did not reply, but saying so bluntly turns a service conversation into an argument. State it neutrally and move immediately to the fix.
Waiting on the requester
Subject: [TICKET-ID] - still need one thing from you Hi [NAME], [TICKET-ID] passed its target at [TIME]. It's been waiting since [DATE] on [SPECIFIC THING]. As soon as that lands, [REALISTIC TIME] to resolve. If it's easier, reply here and I'll call you instead. [YOUR NAME]
If your SLA correctly pauses on waiting states this will rarely fire — which is itself a signal. A queue full of these usually means the pause conditions are wrong rather than the customers are slow.
Major Incident: Many Breaches at Once
When one outage breaches fifty tickets, fifty individual apologies is the wrong response. One message, sent to everyone affected, referencing the incident rather than each ticket.
Bulk notification during a major incident
Subject: [SERVICE] outage - your open tickets We had a [SERVICE] outage from [START] to [END]. If you raised a ticket during that window, it has missed its normal target. Service is: [RESTORED / DEGRADED / STILL DOWN] Your ticket: still open and now back in the normal queue Expect a response by: [TIME] You don't need to re-raise anything. A summary of what happened will follow by [DATE]. [YOUR NAME], [ROLE]
After It Is Fixed
The one most teams skip, and the one that determines whether the breach is remembered. Sent after resolution, it converts a failure into evidence that you run a real service.
Post-resolution follow-up
Subject: [TICKET-ID] - resolved, and what we changed Hi [NAME], [TICKET-ID] is resolved as of [TIME]. It took [DURATION] against a [TARGET] target. Why it ran over: [ONE SENTENCE, NO HEDGING] What we've changed so it doesn't repeat: [SPECIFIC CHANGE] If it recurs, reply here and it comes straight to me. [YOUR NAME]
What to Leave Out
Four things that weaken every one of these:
- The word “unfortunately”. It signals an excuse is coming and the reader braces for it.
- Explaining your internal process. Queues, rotas and routing rules are your problem, not theirs.
- A new date you are not confident about. A second miss costs far more than admitting you do not yet know.
- Repeated apology. Once, early, plainly. After that, actions only.
One structural note: send from a person, not a queue address. A breach notification arriving from no-reply undoes most of what the message is trying to achieve.
Where InfraCue Fits
Full disclosure: this page is published by InfraCue, so treat it as positioning rather than a neutral recommendation. Templates only help if something tells you a target is slipping while there is still time to send the first one on this page.
InfraCue tracks response and resolution targets per priority and category, counts them in working time against a per-customer schedule — weekday windows, holidays including annually recurring ones, timezone-aware across a DST shift — and surfaces at-risk and breached tickets on the dashboard and NOC wallboard, with email alerts to the assigned engineer and infra leads. Device health, tickets, SLA clocks, assets and spares sit in one console. Pricing starts at $39 per month (₹2,999), with a 30-day trial and no credit card.
This page is maintained by InfraCue, an IT operations platform with ticketing, SLA tracking and device monitoring in one console. Templates are free to copy and adapt without attribution.