Outage alerts on Slack, Teams, Discord, webhooks, and email

What triggers an alert

Events are detected by diffing each ingestion run against the last known state, so an alert means something actually changed rather than a page being re-checked. Four event types exist:

• incident.created

  A new incident appeared on the provider's official feed, and only if it started within the last 24 hours. Historical backfills never alert.

• incident.status_changed

  An open incident moved through its lifecycle (investigating → identified → monitoring …).

• incident.resolved

  An incident was resolved upstream, or disappeared from the provider's active feed.

• provider.status_changed

  The provider's overall status changed (e.g., Operational → Partial outage). Never fired from or to an unknown state.

Each subscription can watch all providers (leave the scope empty) or specific providers (aws, cloudflare). Naming services (aws-ec2) or regions (us-east-1) alongside providers narrows what arrives from those providers, and can never reach a vendor the provider list does not contain. A narrowed subscription receives only incidents touching what it named, so provider-level status flips are deliberately skipped.

Regions are offered only for a provider whose feed actually separates them, and are named by that vendor's own code (AWS us-east-1, Google Cloud europe-west4, Oracle Cloud ap-sydney-1) rather than by the place name it prints beside it. An incident a vendor reports without a region still reaches a region-narrowed alert, because narrowing may only drop what a feed positively placed somewhere else. Narrowing is free on every plan, because it only ever means fewer alerts. Naming services or regions with no provider to anchor them is the cross-provider form, which spans the whole catalog and comes with a paid plan, as does the empty whole-stack scope.

Set up Slack, step by step

1. Open api.slack.com/apps → Create New App → From scratch, then name it something like “OutageDeck Alerts” and pick your workspace.
2. In the app's sidebar choose Incoming Webhooks and switch them On.
3. Click Add New Webhook to Workspace and pick the channel that should receive outage alerts (e.g. #outages).
4. Copy the generated URL. It looks like https://hooks.slack.com/services/T…/B…/….
5. On your account page, create a subscription with channel Slack, paste the URL as the target, then hit Send test. The test message lands in the channel within seconds.

Alerts arrive as a one-line summary with a link back to the incident timeline on OutageDeck.

Set up Discord, step by step

1. In your server: Server Settings → Integrations → Webhooks → New Webhook.
2. Pick the channel that should receive alerts.
3. Click Copy Webhook URL (https://discord.com/api/webhooks/…).
4. Create a subscription with channel Discord on your account page, paste the URL, and hit Send test.

Discord alerts render as an embed with a severity color and a link to the incident.

Set up Microsoft Teams, step by step

1. In Teams, open the channel that should receive alerts and click ⋯ → Workflows.
2. Pick the template “Post to a channel when a webhook request is received” and create it.
3. Copy the request URL the workflow shows (it looks like https://prod-….logic.azure.com/workflows/…).
4. Create a subscription with channel Microsoft Teams on your account page, paste the URL, and hit Send test.

Teams alerts arrive as an Adaptive Card carrying the incident title, the one-line summary, the provider's latest update when there is one, and a button to the incident timeline.

Generic webhooks and the JSON contract

Point a subscription at any HTTPS endpoint you control and OutageDeck POSTs this envelope on every matching event. The shape is versioned like the public API (meta.version: "v1") and will not change under you:

{
  "meta": {
    "version": "v1",
    "kind": "outagedeck.alert",
    "generatedAt": "2026-07-12T09:40:00.000Z"
  },
  "data": {
    "event": {
      "key": "incident:aws:INC-123:investigating",
      "type": "incident.created",
      "occurredAt": "2026-07-12T09:40:00.000Z",
      "summary": "🔴 AWS new incident: Increased error rates in us-east-1 (Investigating, Critical severity)",
      "url": "https://outagedeck.com/incidents/aws-increased-error-rates-us-east-1-2026-07-12",
      "provider": { "id": "provider_aws", "slug": "aws", "name": "AWS" },
      "incident": {
        "id": "incident_aws_INC-123",
        "slug": "aws-increased-error-rates-us-east-1-2026-07-12",
        "title": "Increased error rates in us-east-1",
        "status": "investigating",
        "previousStatus": null,
        "severity": "critical",
        "startedAt": "2026-07-12T09:31:00.000Z",
        "officialUrl": "https://health.aws.amazon.com/health/status",
        "affectedServiceSlugs": ["aws-ec2", "aws-s3"],
        "affectedServiceNames": ["EC2", "S3"],
        "latestUpdate": {
          "status": "investigating",
          "body": "We are investigating increased error rates and latencies in the us-east-1 Region.",
          "createdAt": "2026-07-12T09:38:00.000Z"
        }
      },
      "providerStatus": null
    }
  }
}

For provider.status_changed events, incident is null and providerStatus carries { "from": "...", "to": "..." }. affectedServiceNames and latestUpdate (the provider's newest human-written update, clamped to 600 characters) are optional; treat them as absent when the detecting run did not have them. Answer with any 2xx within 10 seconds; the body is ignored.

Email

Pick the Email channel and alerts go to your account address, the same one you sign in with. Each email carries the summary line, a link to the incident on OutageDeck, and the provider's official status-page entry when one exists.

Paid plans can also send to a devops group, an on-call alias, or a client. Add the address under Alert recipients on your account and we email it a confirmation link; it becomes selectable once someone reading that mailbox clicks. That click is the whole gate, and it is deliberately not something a plan can buy: OutageDeck will not mail an address that has not agreed to hear from it. Every alert to such an address carries a one-click link that removes it, with no sign-in and no need to ask you first, and delivery is re-checked on every run, so a removal or a lapsed plan stops the mail immediately.

Delivery guarantees

• Exactly once per event. Every (subscription, event) pair is claimed in a delivery ledger before sending, so overlapping check runs can never double-notify you.
• 10-second timeout, one retry. Failed deliveries (5xx, 429, network) are retried once, and the outcome is recorded either way.
• Flap suppression. An incident transition is keyed by its target state, so the same change observed twice never alerts twice. Provider-level status keys reset daily.
• Test any time. Every subscription has a Send test button on your account page that fires a clearly labeled synthetic alert through the exact production pipeline, so you can verify the wiring in seconds instead of waiting for a real outage.

Plans

Alerts start free: any account can create email alerts for up to 5 named providers, narrowed to their services and regions if you want, no card required. Paid plans add the Slack, Teams, Discord, and webhook channels, unlimited providers, and the whole-stack and cross-provider scopes: Starter includes 5 subscriptions, Pro 20, and Business 50. See pricing. Checkout takes a minute, and your API key plus the paid channels are live right after.