Notifications

A monitor on its own just watches — to actually hear about a problem, you connect a destination for CuliPulse to send the alert to.

Supported destinations

• Email — on by default for new accounts, to the address you signed in with.
• Telegram — get alerts as messages from a bot, in a private chat or a group.
• Slack — get alerts posted into a channel you choose.
• Webhook — CuliPulse sends the alert as a signed HTTP request to a URL you control, so you can wire it into your own tools.

Connect a destination

1. Go to Notifications → Add destination.
2. Choose the type and connect it:
   • Telegram — open the link CuliPulse gives you and press Start in Telegram (or add the bot to a group). CuliPulse confirms with a message once it’s connected. The link works for 15 minutes. See Telegram.
   • Slack — click Add to Slack, pick the channel, and approve. Alerts post there via an incoming webhook. See Slack.
   • Webhook — provide the HTTPS URL to send alerts to. See Webhooks.
3. Send a test alert to confirm it arrived. Tests are spaced about 30 seconds apart per destination; if you press again too soon, CuliPulse tells you how many seconds to wait. A test looks like a real alert, but it is always marked: the title starts with TEST and a line says This is a test, nothing is down. Nothing is wrong when you get one, so it is safe to send to a team channel.
4. Choose which monitors alert to this destination — all of them, or a specific set. A specific set needs at least one monitor: pick one, or choose All monitors. A destination with no monitors would never send anything, so CuliPulse won’t save it. A destination set to specific monitors does not pick up monitors you add later. Only All monitors does. A monitor’s page shows Alerts go to: so you can see what covers it. Agent offline and online alerts (when one of your own agents stops or resumes checking in) go to every destination set to All monitors, and to a destination set to specific monitors when it covers at least one monitor that agent checks.

One destination can serve many monitors, and one monitor can alert to many destinations. You can have up to 20 destinations per account (email counts as one). A Telegram or Slack connection you started but never finished counts too, until you delete it. If you reach the limit, remove one you no longer use to add another.

New accounts get email on automatically — it doesn’t need connecting. Don’t see an Email row? Choose Add destination, then Email under Other channels, and Turn on email alerts. See Email for details.

Check that alerts can reach you

The header on Notifications counts the destinations that can receive an alert right now, for example 2 receiving · 1 need attention. A destination that is off, still waiting to connect, has an expired link, covers no monitors, or whose last delivery failed does not say Connected, and the Alerts routed step on the Getting started list counts only destinations that are on and cover at least one monitor. When an alert couldn’t be delivered, the row turns amber and says what happened, for example A delivery failed 4 min ago: Telegram says the bot was blocked or removed from this chat. See Not getting alerts?.

Once connected, a destination shows in your list where you can rename, pause, send another test, change which monitors use it, or remove it (Email: on/off and test only).

What an alert contains

Alerts are written in plain language — the state, a short symptom (the real cause), which locations saw the problem, and how long it’s been going. If a monitor checks from several locations and only some of them are reporting when it goes down, the Telegram, Slack and email alerts add one line saying how many are reporting and which are silent, so you know the result may not reflect every location. See Alerts & states for the details, and the webhook payload for the exact machine-readable shape.

When delivery fails

Each destination gets its own copy of every alert, delivered on its own. If one destination fails, your other destinations still get the alert, once.

• A temporary problem (the service is down, too busy, or slow to answer) is retried a few times over two to three minutes, waiting longer if the service asks CuliPulse to slow down. After the last try, CuliPulse stops trying that alert for that destination.
• A problem retrying can’t fix is not retried: for example, a Telegram chat where the bot was blocked or removed, a Slack app that was uninstalled, or a webhook that answers with an error such as 404. Reconnect or fix the destination, then send a test alert.

CuliPulse records the time and reason of a destination’s failure (at most once an hour, so the time shown can be up to an hour behind the latest failure), and clears it as soon as a delivery to that destination works again. Webhook specifics (status codes, Retry-After, ordering) are on the Webhooks page.

Need a different channel?

If you need a destination CuliPulse doesn’t support yet, the Notifications page has a Request a channel form — tell us what you need.

Using notifications from your own code

If you’d rather receive alerts in your own system directly, a webhook destination or the API are the way to integrate CuliPulse with your existing tools.