Alerts you can audit

Channels

• Email — what happened, since when, which probe regions confirmed it, and a link straight to the check.
• Telegram — through a bot okokumo runs, so setup is pressing Connect and then Start rather than registering a bot of your own.
• Slack — an incoming webhook you paste in, delivered as formatted blocks, with a test send from the interface.
• Discord — an incoming webhook you create in your own server (Channel → Edit Channel → Integrations → Webhooks), pasted in the same way. Alerts arrive as an embed — red for down, green for recovery, grey for paused — carrying the state change, the time, the reason and the target, with the title linking back to the check. Nothing to install and no bot to invite.
• Webhook — signed JSON over HTTPS to any endpoint, retried with backoff, with a documented payload. Every delivery carries an HMAC signature so the receiver can verify it came from us.

There is no SMS and no phone call. Both are on the list of things this product does not do.

A channel receives nothing until it is confirmed

Adding a channel is two steps, not one. Email validates when you click the link sent to that address; webhook, Slack and Discord validate the moment a test delivery succeeds. Until then the channel exists but is pending, and pending channels receive nothing.

This is deliberate, and it is worth understanding rather than working around: it guarantees an alert never goes to a destination nobody confirmed — a typo'd address, a webhook that was never reachable, a Slack channel that was deleted. The cost is that a check can go down without paging you if its only channel was never confirmed, which is exactly why the delivery log below exists and says so.

Routing

Channels can be attached to specific checks, or left as the organization default that covers everything. So the customer-facing API can page a phone through Telegram while a nightly batch job posts to a Slack room nobody watches at 3am.

One incident, one alert

A down transition sends once. While the state is unchanged, nothing renotifies — a service that is down for six hours does not produce six hours of messages, because a channel that cries wolf gets muted, and a muted channel is worse than no monitoring at all. Recovery sends its own notification, so silence never has to be interpreted.

Underneath, a failure has to be confirmed from a second independent EU probe region before any of this starts. How that works →

The part nobody else shows you

app.okokumo.com/checks/api

Every check keeps a delivery log: what was sent, to which channel, when — and what was skipped, with the reason. Deduplicated because the state had not changed. Skipped because the channel was still pending. Failed because the endpoint returned a 500.

Every monitoring product claims it alerts you. This is the claim that can be checked, and it is the reason the log is a feature rather than an internal table.

Through the API

Alerts for a check are readable over the versioned REST API with an organization key, alongside checks, statuses and results. Documentation →