Guide

Alert Channels

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

Every enabled channel receives two kinds of alert:

• Vendor incident: the vendor declared an active incident, outside scheduled maintenance, on a service your organization tracks. When that service covers only some components of a shared status page, an incident that names only other components is not sent. The alert shows the vendor's own severity label; the label never decides whether it is sent.
• SDK failures: at least 5% of at least 20 calls from your SDK to that vendor failed in a five-minute window. Server errors, network errors and timeouts count; 4xx responses do not. Every alert prints the threshold it crossed.

Each alert that is sent, suppressed or fails is recorded with its reason.

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 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.

Telegram

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.

Send a test to 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 vendor incident alert.
• sdk.failures: your SDK's calls to a vendor failed; sdkFailures carries the counts, window and threshold.
• 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.

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.