Primary signal
Response
Incidents get caught faster
Critical alerts reach the on-call the moment they fire, so real incidents are caught before they spread.
Realtime System Alerts
Ship this workflow
Pick how you want to build it.
Try it in the dashboard Fastest
Go to Workflows → New Workflow → Use sample workflow in your workspace, and select this workflow.
Try it
Build with the SuprSend Agent
Build with SuprSend MCP
When to use this workflow
Critical incidents get lost among low-priority alerts. The one alert that needs action now sits in the same stream as routine noise.
Every alert paging the on-call at all hours burns them out. A warning that could wait wakes someone at 3 AM.
A critical alert on one channel is missed and the incident grows. An email left unread while an outage spreads costs real time.
A flood of low-severity noise trains the team to ignore alerts. Once everything is muted, the real incident is muted too.
How it works
1
An alert fires
When a system alert is raised (SYSTEM_ALERT), it is routed by its severity.
TriggerBranch
2
Critical pages the on-call at once
A critical alert goes out immediately on push, email, and SMS.
Multi-Channel
3
Warnings are grouped
Warning alerts are batched, then sent, so a burst becomes one notification.
BatchMulti-Channel
4
Low alerts become a digest
Low-severity alerts are collected into a single quiet digest.
BatchMulti-Channel
Best practices
Page critical alerts immediately, batch the rest
An outage cannot wait; a warning can. The Branch on severity sends critical now and groups the rest, so the on-call sees the real one.
Put the critical alert on a channel that wakes someone
Email alone does not cut it for a 3 AM outage. Critical adds SMS and push so it reaches the on-call off the app.
Make the alert say what broke and what to do
"API error rate 40%, runbook attached" beats "something is wrong". A specific alert with a next step saves the on-call from investigating from scratch.
Common mistakes to avoid
Labeling everything critical
If every alert is critical, none is. Reserve critical for what genuinely needs someone now, or the on-call mutes the lot and misses the real one.
Paging the same person for every kind of alert
A database alert and a billing alert need different owners. Route by the system or team so the right on-call gets the page, not one person for everything.
No way to acknowledge or dedupe a repeating alert
A flapping alert pages over and over. Let the on-call acknowledge it, or dedupe so one incident is one page, not fifty.
What users receive
The actual notifications this workflow sends, on each channel.
Low Severity System Alert
Email
In-app inbox
System Critical Alert
Email
SMS
Android push
iOS push
System Warning Alert
Email
Android push
iOS push
What good looks like
Fatigue signal
Alert fatigue
The team mutes the alerts
When the on-call starts ignoring alerts, too many are marked critical or firing as their own page instead of being grouped.
Support
Frequently Asked Questions
Quick answers about setting up and running this workflow.
Critical on push, email, and SMS; warnings on push and email; and low-severity alerts as an email and in-app inbox digest.
A Batch groups them into one digest instead of a notification each, so routine noise does not bury the alerts that matter.
Around 30 minutes by default, configurable on the Batch, so a quiet digest replaces a constant stream.
Fire SYSTEM_ALERT at each severity and watch critical page immediately while the others group. Trigger from the Test button, the SuprSend Agent, or the API, CLI, or MCP.
Ship Realtime System Alerts in under 5 minutes.
Try directly in SuprSend
FastestSign up and test the workflow directly in the dashboard.
Build with the SuprSend Agent
Copy the prompt, paste it into the Agent in your SuprSend dashboard, and the workflow gets built for you.
Build it with SuprSend MCP
Set up SuprSend MCP in Claude Code, Cursor or Windsurf, copy the prompt, and the workflow builds itself in your workspace.