Your site goes down at 11pm. Within five minutes, your on-call developer gets an email. They check. It's not their code - the hosting provider is having issues. They wait. Twenty minutes later, the site is still down, and now your account manager gets an alert too. At the thirty-minute mark, the CTO's inbox lights up. Nobody had to make a phone call. Nobody had to forward an email. The escalation happened automatically, because each notification channel had its own delay configured in advance.
That's what per-channel alert delays do. And as of today, they're live in SiteVitals.
What changed
Previously, SiteVitals had a single "alert after X minutes" setting per site. If your site went down and that threshold was met, every notification channel fired at the same time - your email, your Slack webhook, your in-app alerts - all at once, all with the same delay.
That's fine for simple setups. But for teams with any kind of on-call structure, it's not enough. You don't want to wake up the CTO for a blip that lasts three minutes. And you don't want your front-line developer to only find out about an outage thirty minutes in because the delay was set high to avoid noise.
Now, each notification channel has its own Uptime Alert Delay setting. You configure it per channel in your site's Notifications section, and SiteVitals handles the rest. Different channels, different thresholds, same incident.
How it works
When SiteVitals detects that your site is down, it creates an incident and starts tracking how long the outage has lasted. On every subsequent uptime check, it compares the incident duration against each channel's configured delay.
A channel with no delay (or a delay of zero) fires immediately on the first failed check - exactly as before. A channel with a 15-minute delay won't fire until the incident has been open for at least 15 minutes. A channel with a 60-minute delay stays quiet until the outage hits an hour.
Each channel is independently tracked. If the site recovers before a channel's threshold is reached, that channel never fires at all. No unnecessary noise, no "sorry, false alarm" follow-up.
Why this matters: building an escalation chain
The most powerful use of per-channel delays is building escalation paths without any external tooling. Here are a few scenarios where this changes how you respond to downtime.
The on-call developer, then the manager
Set up two email channels. The first sends to your on-call developer with a 5-minute delay - long enough to filter out a momentary hosting hiccup, short enough to catch a real outage fast. The second sends to your engineering manager with a 30-minute delay. If the developer has already resolved the issue within half an hour, the manager never gets bothered. If it's still going at the 30-minute mark, the right person now knows about it.
Slack for the team, email for the client
Your internal Slack webhook fires immediately - your team needs to know as soon as possible. But your client's email channel is set to 15 minutes. Most brief outages resolve before the client ever hears about them. If the outage persists, the client gets a professional notification and knows you're already on it - because you were alerted 15 minutes earlier.
Agency managing 30 client sites
If you're an agency on the Agency plan, you're monitoring up to 30 sites. Not every site has the same criticality. For your highest-value client, your in-app alert fires immediately and your developer gets an email after 2 minutes. For a smaller brochure site, maybe you only want to know if it's been down for 10 minutes - anything shorter is probably a transient hosting issue and not worth the context switch.
Where to find it
Head to any site's configuration page and scroll to the Notifications section. For each channel that has the "Uptime" alert type enabled, you'll see a new Uptime Alert Delay (Minutes) field. Enter the number of minutes you'd like SiteVitals to wait before alerting that channel, or leave it empty to alert immediately.
The old site-level "Alert After Minutes" setting has been retired - your existing value has been migrated to all of your current channels, so nothing changes unless you want it to.
Works with every channel type
Per-channel delays work across all supported notification types: email, Slack webhooks, custom webhooks, and in-app notifications. You can mix and match freely. An immediate Slack alert, a 10-minute email to your developer, and a 30-minute webhook to your incident management tool - all running independently, all from the same uptime monitor.
Combined with Change Intelligence, which logs every uptime event to your site's timeline alongside SEO shifts, security changes, and content updates, you now have both the alerting precision and the historical context to handle incidents properly - from first detection to post-mortem.
Taking it further: SMS escalation via webhooks
SiteVitals doesn't offer SMS alerting directly - and that's deliberate. SMS delivery involves carrier costs, regional compliance rules, and per-message billing that would complicate our pricing. But the good news is that our webhook channel makes it straightforward to add SMS to your escalation chain using a third-party service. Here are three approaches, ranging from zero-code to fully custom.
Zapier: webhook to SMS in five minutes
The quickest way to get SMS alerts from SiteVitals is with Zapier. Create a Zap that uses "Webhooks by Zapier" as the trigger (Catch Hook) and "SMS by Zapier" as the action. Zapier gives you a webhook URL - paste that into a SiteVitals webhook channel, set the alert delay to whatever escalation threshold you want, and you're done. When the webhook fires, Zapier sends an SMS to the phone number you've configured.
Zapier's built-in SMS is limited in volume, but for critical escalation alerts that only fire after 30 or 60 minutes of downtime, you won't hit those limits. If you need higher volume or international numbers, Zapier also integrates with dedicated SMS providers like Twilio, MessageBird, and Vonage - same principle, just swap the action step.
PagerDuty: full incident management with phone and SMS
If your team already uses - or wants to use - a proper incident management platform, PagerDuty is the obvious choice. PagerDuty accepts webhook integrations and can notify responders by SMS, phone call, push notification, and email. It also has its own escalation policies, on-call scheduling, and acknowledgement tracking.
The setup is simple: create a PagerDuty service with a webhook integration, copy the integration URL into a SiteVitals webhook channel, and set the alert delay. SiteVitals handles the "when" - how long to wait before escalating - and PagerDuty handles the "how" - routing the alert to the right person via SMS or phone call. PagerDuty's free plan includes 5 users and 100 SMS/phone notifications per month, which is plenty for an escalation-only channel that's designed to fire rarely.
This combination is particularly powerful. You might have SiteVitals send email and Slack alerts immediately, then fire a webhook to PagerDuty after 30 minutes with per-channel delays. PagerDuty then takes over with its own escalation - calling your on-call engineer, and if they don't acknowledge within 10 minutes, calling their manager. Two layers of escalation, working together.
Twilio: direct webhook-to-SMS for developers
If you'd rather skip the middleman, Twilio lets you build a lightweight webhook endpoint that receives the SiteVitals payload and fires an SMS via their Programmable Messaging API. This is a few lines of code - a simple serverless function on AWS Lambda, Cloudflare Workers, or even a Laravel route on your own server. You get full control over the message format, recipient logic, and costs (Twilio charges fractions of a penny per SMS in most countries).
The SiteVitals webhook sends a JSON payload containing the site URL, alert type, severity, and message. Your endpoint parses it and calls Twilio's API. Total development time: about 15 minutes if you've used Twilio before.
Putting it all together
Here's what a complete escalation chain might look like using per-channel delays and a mix of native and third-party channels:
| Delay | Channel | Who gets it |
|---|---|---|
| 0 minutes | In-app notification | Everyone on the team |
| 0 minutes | Slack webhook | #ops-alerts channel |
| 5 minutes | On-call developer | |
| 15 minutes | Webhook → Zapier → SMS | On-call developer's phone |
| 30 minutes | Engineering manager | |
| 30 minutes | Webhook → PagerDuty | Phone call to CTO |
| 60 minutes | Client stakeholder |
Every row is a separate SiteVitals notification channel with its own delay. The in-app and Slack alerts fire instantly. The developer gets an email after 5 minutes and an SMS after 15. The manager gets looped in at 30. The CTO gets a phone call at 30 via PagerDuty. The client only hears about it if the outage lasts an hour. If the site recovers at the 12-minute mark, only the first three channels ever fire - the rest stay silent.
No external orchestration tool required. No code running your escalation logic. Just channels with delays.
Available now
Per-channel alert delays are live now for all sites on all plans, including the free plan. If you're already using uptime monitoring, your existing configuration has been preserved - you can start customising individual channel delays whenever you're ready.
If you're not using SiteVitals yet, sign up for free and you'll have uptime monitoring with per-channel alerting running in under a minute.
By Tom Freeman · Co-Founder & Lead Developer
Full-stack developer specialising in high-performance web applications and automated monitoring.