Guide

Alert Channels

Add a destination in Settings → Alerts, choose a minimum severity and send a test. Alerts identify vendors to investigate; they do not confirm that your app failed.

Free includes email. Pro and Enterprise include the twelve channels below. See plan limits.

Email

Select Email and save. No destination credentials are needed. Delivery follows organization membership and each person's notification preferences.

Slack

Create a Slack incoming webhook (opens in new tab), then select Slack and paste its URL. Step-by-step setup.

Discord

In Discord, open Channel Settings → Integrations → Webhooks. Create a webhook, then select Discord in CheckUpstream and paste the URL.

Microsoft Teams

Create a Workflows webhook for the Teams channel. Select Microsoft Teams and paste the workflow URL. Teams setup.

PagerDuty

Add an Events API v2 integration to your PagerDuty service. Select PagerDuty and paste the routing key.

Degraded maps to warning, partial outage to error, and major outage to critical. CheckUpstream triggers and updates the incident; your team manages acknowledgement in PagerDuty.

OpsGenie

Create an OpsGenie integration API key. Select OpsGenie and paste the key. Degraded maps to P3, partial outage to P2, and major outage to P1. Manage acknowledgement in OpsGenie.

When paging alerts close. For both channels, CheckUpstream requests closure after the vendor explicitly marks its incident resolved, provided the alert is still active, unmuted and on an enabled channel with the original routing key or integration API key. A missing feed entry, tracking timeout or unknown closure reason leaves the paging alert open.

Changing the routing key or integration API key does not redirect older alerts. Manage those alerts in the original paging service.

Vendor resolution does not establish application recovery. Check your own measurements before closing your team's incident.

Google Chat

In your Chat space, open Apps & integrations → Webhooks. Create a webhook, then select Google Chat and paste its URL.

Create a bot through @BotFather (opens in new tab), add it to the receiving chat, then select Telegram and enter its bot token and chat ID. Find your chat ID.

SMS

SMS uses your Twilio account. Select SMS and enter:

Account SID and Auth Token from Twilio.
From Number: your Twilio sender number.
To Numbers: comma-separated recipients, including country codes.

Choose a minimum severity and check delivery. Twilio's messaging charges apply to your account.

Webhook

Select Webhook, enter your endpoint URL and set a signing secret. Deliveries use POST with a flat JSON body:

incident.detected: the initial incident alert.
incident.updated: a later status or severity update.
incident.resolved: the tracked record closed. Check resolution; this does not always mean the vendor recovered.
alert.test: a test from alert settings.

Updates and closure notices go only to the original webhook URL while its channel is enabled and the alert remains unmuted. Changing the URL does not redirect notifications for older alerts.

Verify X-Checkupstream-Signature against an HMAC-SHA256 of the raw body. It is a bare hex digest, without an algorithm prefix. The header is only included when a secret is configured.

Copy the verification example and payloads. Handle each event by type; update and closure payloads differ from the initial alert.

predictedResolution uses historical incident start and closure timestamps. Closure can reflect a feed entry disappearing or tracking expiring. It does not confirm recovery or estimate minutes remaining.

Initial incident payload fields

WebhookPayload

eventstringRequired: The initial alert uses "incident.detected". Update, closure and test events have separate payloads in the webhook reference.
serviceIdstringRequired: Identifier of the upstream service
serviceNamestringRequired: Display name, e.g. "Stripe"
incidentIdstringRequired: Identifier of the incident
titlestringRequired: Incident title, e.g. "Elevated API Error Rates"
impactstringRequired: Impact level: "degraded", "partial_outage", or "major_outage"
affectedProjectsobject[]Required: Your projects that depend on the service
enrichmentobjectRequired: The full enrichment bundle: summary, affected and surviving capabilities, mitigations, regions, error-rate and latency deltas, recurrence count
predictedResolutionobject | nullRequired: Historical recorded incident duration, or null when there is not enough history to publish one
timestampstringRequired: ISO 8601 timestamp of the delivery

Rootly

Select Rootly and enter an API key with incident creation access. The test checks the key with a read request; it does not create an incident. Review and close real incidents in Rootly after recovery.

Incident.io

Select Incident.io and enter an API key with incident creation access. The test checks the key with a read request; it does not create an incident. Manage real incidents in your Incident.io workflow.

Check delivery

Use the channel's Test button after saving. If the test fails, check the destination, credentials and receiver filters. Webhook receivers should keep alert.test separate from incident notifications and inspect the closure reason before changing incident state.

Add your alert destination

Choose a channel your team checks during an incident.

Open alert settings Integration recipes