Notifications overview

The six notification channels, what actually dispatches to them today, and the one big thing that does not.

Last updated August 5, 2026

An integration is a destination you configure once — a Slack channel, an on-call inbox, an ntfy topic, an HTTPS endpoint — and StatusOwl delivers to. Each is an independent record with its own settings and its own on/off toggle. There is no cap on how many you create, and all six channels are available on every plan.

Read the next section before you build anything on top of them.

What dispatches today

A failing uptime check does not notify you

This is the single largest gap in StatusOwl and it is stated here rather than buried. A failing HTTP, ping or TCP check dispatches nothing. No email, no Slack message, no webhook.

What it does do is open an incident on your status page, if the page has automatic incidents turned on. Your customers find out. You do not, unless you are looking.

The same is true of SSL and domain expiry thresholds: crossing one changes the dashboard, and dispatches nothing.

Uptime alerting is being built right now — it is the top item on the roadmap. This page will change the day it ships.

Two things dispatch to your integrations today, and only two:

Send Test. Every integration has a Send Test button that fires a real delivery through the real code path. Use it after every change — URL updates, secret rotations, channel renames.
Watch Owl alert rules. When a host-metric rule — CPU, memory, disk, network, pending updates, reboot required, host offline — fires or resolves, StatusOwl dispatches to every integration that rule is routed to. This is a complete, production alerting path. It just only covers metrics from Watch Owl agents on your own hosts.

The six channels

Channel	Transport
Email	Direct to one or more addresses. No OAuth, no key.
Slack	Incoming webhook, one channel per webhook.
Discord	Incoming webhook, rich embeds.
Microsoft Teams	Incoming Webhook connector, or a Workflows URL on connector-disabled tenants.
ntfy	Push to ntfy.sh or your own server, with priority and tags.
Webhook	Signed JSON to any HTTPS endpoint you control.

All six are real, all six are in production, and all six have a live test send.

What does not exist

Stated plainly, because these get assumed:

SMS and phone calls. Not built, not planned.
PagerDuty, Opsgenie or any on-call connector. Not built. Route through a webhook if you need to reach one.
On-call rotations and escalation policies. Not built. Every integration a rule routes to receives the notification at the same moment.
Status page subscribers. Visitors cannot subscribe to a page, and there is no subscriber list. Publishing an incident notifies nobody. On the roadmap.

The per-integration event flags

When you create an integration you can pre-select monitor down, monitor recovery and maintenance mode events. These flags save, the API returns them, and nothing consumes them yet — they are the configuration half of a feature whose dispatch half is still being built. Setting them today has no effect. They are left in place so that no migration is needed when dispatch ships.

Getting notified about downtime today

If you need to know your own service is down, and you own the host:

Install Watch Owl on it.
Create a host_offline_seconds alert rule (how).
Route the rule to whichever integrations you want.

That path is live and it does dispatch. It tells you the host stopped reporting, which is not the same as your service returning 500s — but it is the one alerting route that works end to end today.

Multiple integrations of the same type

Nothing stops you creating several. One Discord webhook for on-call and another for general engineering; separate email integrations for internal and stakeholder audiences. Each Watch Owl alert rule then picks the integrations it should reach, so different metrics can go to different places.

Permissions

Creating, editing and deleting integrations requires Member or above — Owner, Admin, Billing and Member all qualify. Viewer cannot. See Roles & permissions.