Notification channels

A channel is somewhere alerts are delivered. You can have several, and choose which monitors use which.

Available: Email, Slack, Microsoft Teams, Discord, Webhook.

If you configure nothing

We email every member of the team. That is a deliberate fallback — monitoring that alerts nobody is worse than no monitoring, because you believe you are covered.

It is a safety net, not a configuration. As soon as there is more than one person on the account, somebody is getting email they do not want and somebody else is assuming a colleague is watching.

Always send a test

Every channel has a Send test button. Use it. A webhook URL with a typo, a Slack app removed from the workspace, a Teams connector someone retired — all of these fail silently at exactly the wrong moment. The test is the difference between finding out now and finding out during an outage.

Email

Add the address and send a test. Check the spam folder if nothing arrives, and allow-list the sender.

Shared mailboxes work well for teams. Personal addresses work badly for anything you need acted on when that person is on holiday.

Slack

You need an incoming webhook URL from Slack:

1. In Slack, go to Apps and add Incoming WebHooks (or create an app at api.slack.com/apps and enable Incoming Webhooks).
2. Choose the channel to post into.
3. Copy the webhook URL — it looks like https://hooks.slack.com/services/T000/B000/XXXX.
4. Paste it here and send a test.

Treat the URL as a secret: anyone holding it can post into that channel.

Microsoft Teams

You need a workflow or incoming webhook URL for the channel:

1. In Teams, open the channel's menu and choose Workflows (newer) or Connectors → Incoming Webhook (older).
2. Create one, name it, and copy the URL.
3. Paste it here and send a test.

Microsoft has been retiring Office 365 connectors in favour of Workflows; if the connector route is missing or your webhook stops working, that is why — create a Workflow instead.

Discord

1. In Discord, open Channel settings → Integrations → Webhooks.
2. New webhook, pick the channel, and Copy webhook URL.
3. Paste it here and send a test.

Webhook

For anything else: your own endpoint, an incident tool, a script.

We POST JSON:

{
  "source": "uptimecraft",
  "subject": "DOWN: Marketing site",
  "message": "Marketing site is down (connection refused)",
  "timestamp": "2026-10-04T02:31:07.412Z"
}

• source is always uptimecraft, so one endpoint can serve several senders.
• subject is the one-line summary.
• message is the detail as plain text.
• timestamp is when we sent it, in UTC.

There are no retries. If your endpoint is down or returns an error, that notification is gone — we do not queue it and try again. Said plainly because the opposite assumption is dangerous: if a webhook is your only channel, an outage that takes out your receiver takes out your alerting with it. Keep a second channel that does not depend on your own infrastructure.

Your endpoint should answer quickly and do its real work asynchronously.

What about PagerDuty, Opsgenie and SMS?

Not built yet, and not offered. You will not find them in the list, and this page will say so when that changes.

For PagerDuty or Opsgenie today, both accept inbound webhooks — point a Webhook channel at their events endpoint.

Choosing which monitors use a channel

On a monitor, under notifications, either send to every channel or pick specific ones. The usual arrangement is everything to a Slack channel, and the few things that genuinely justify waking somebody to a second channel that reaches a phone.