Getting Started with Alerts

Overview

This guide introduces AppStatus Alerts and covers:

• 12 notification channel types (Email, Slack, Teams, Discord, Webhook, SMS, WhatsApp, Telegram, Pushover, Phone, Web, Chat)
• Alert rules with condition-based triggers
• Multi-level escalation policies with quiet hours and on-call rotation
• Alert lifecycle: firing → acknowledged → resolved
• Delivery tracking with full event history
• Test dispatch to verify channels before incidents

What are AppStatus Alerts?

Alerts transform monitor and incident signals into actionable notifications delivered through your team's preferred channels. When a monitor goes down, an SSL certificate nears expiry, or latency spikes, alert rules evaluate the event against configured conditions and dispatch notifications through bound channels with priority, severity, and escalation logic.

The alert system supports 12 notification channel types — from email and Slack to phone calls and custom webhooks — each with type-specific configuration validation. Escalation policies define multi-level notification chains with configurable delays, repeat intervals, quiet hours, and on-call schedules so critical alerts always reach the right person.

Key capabilities:

• 12 channel types: Email, SMS, Slack, Teams, WhatsApp, Webhook, Web Push, Pushover, Telegram, Discord, Phone, Google Chat
• 5 condition types: monitor_issue, uptime_down, latency_spike, ssl_expiry, response_error
• 4 severity levels: critical, error, warning, info
• 4 priority levels: critical, high, medium, low
• Up to 5 escalation levels per policy with independent delay and retry config
• Quiet hours with timezone-aware scheduling
• On-call rotation support
• Priority-based routing (different escalation chains per severity)
• Full delivery tracking: queued → sent → delivered → failed

Alert Workflows

Each workflow maps to real AppStatus features and API endpoints used in the main app.

Troubleshooting

Operational Guidance

• Keep critical and informational channels separate.
• Revalidate credentials after any channel provider update.
• Use explicit escalation ownership for every severity tier.

Step-by-Step Setup

Alerts turn raw monitor failures into useful notifications on the channels your team actually watches. You set up channels once (Slack, Email, SMS, etc.), then create rules that decide which channel gets which kind of alert and when to escalate. Most teams need 5 minutes to set up their first end-to-end alert.

1. 1

   Open Alerts → Channels

   A channel is a reusable delivery target — one email distribution list, one Slack webhook, one SMS number, etc. You build them once and then attach them to as many monitors and rules as you want.

   WhereSidebar → Alerts → Channels tab
2. 2

   Click "+ New channel" and pick the type

   A dropdown lists all twelve channel types. Email and Slack are the most common starting points — see the channels table below for what each one needs from you.

   WhereChannels → + New channel
3. 3

   Fill in the channel form

   Each channel type asks for what it needs — recipients for Email, webhook URL for Slack, phone number for SMS, etc. Give the channel a clear name (e.g. "On-call Slack", "Billing email list") so future-you knows which is which.

   WhereChannel form → Name, Type, Type-specific config, Enabled
4. 4

   Test the channel before you trust it

   Click "Send test" on the channel detail page. AppStatus dispatches a sample alert payload immediately and shows whether delivery succeeded. Fix the credentials before moving on — you do not want to discover a broken webhook during a real outage.

   WhereChannel detail → Send test (top-right)

   Tip

   For Slack: the test message arrives in the same channel the webhook is bound to. For SMS: charges apply per test.

5. 5

   Switch to the Rules tab and click "+ New rule"

   A rule binds three things together: which monitors it applies to, what condition triggers it, and which channels to notify. You can scope a rule to one monitor or to all monitors in the workspace.

   WhereAlerts → Rules → + New rule
6. 6

   Configure the trigger condition

   Pick the condition type (most teams start with "Monitor goes DOWN" with 2 consecutive failures to avoid flapping). Add the severity (low / medium / high / critical), then choose the channels that should be notified.

   WhereRule form → Condition type, Consecutive failures, Severity, Channels
7. 7

   Add escalation (optional but recommended)

   Tell the rule what to do if the first responder does not acknowledge within a time window. A common pattern is: page Slack first → escalate to SMS after 10 min → escalate to manager email after 30 min.

   WhereRule form → Escalation → Escalate after, Repeat every, Then notify
8. 8

   Set quiet hours (optional)

   For non-critical rules, suppress notifications during night-time hours so you do not get paged for a flaky job at 3am. Critical-severity rules ignore quiet hours by design.

   WhereRule form → Quiet hours → Start, End, Timezone
9. 9

   Save and verify

   After saving, the rule is live immediately. On the rule detail page, the Delivery tab shows every alert that has been sent, when it was acknowledged, and which channel delivered it.

   WhereSave → Rules list → click the rule → Delivery tab

Configuration Options

Every option you can set, what each choice means, and what to pick. Use this as a reference while you fill in the form.

Feature Reference

Every feature, where to find it in the app, and what it does. Use this when you know what you want to do but not where it lives.

Next Steps

Continue building your monitoring stack: