Alerts

Configure when alerts fire, where they go (email, Slack or Discord) and how often they repeat.

When an alert fires

Rippler sends two kinds of alert:

Down: the monitor stopped reporting. Either grace ran out on an expected ping, the job pinged /fail/, or a website check failed on its retry too. The alert says why, such as No ping arrived in time or HTTP 502, confirmed on retry.
Up: it recovered from being down.

A recovery alert is only sent for an outage that was alerted on. If a monitor went down and came back without reaching your failure tolerance, you get neither message.

Nothing is sent for a monitor in grace.

Where alerts go

Email

To every member of the team that owns the monitor. A monitor belongs to a team, not a person.

Each person controls their own delivery with the alert emails setting on their profile. Switching it off stops alerts for that person only. It does not change what the team alerts on. The team members list shows who has it off.

Slack and Discord

Each project can post its alerts to a Slack channel, a Discord channel, or both. The webhook is set per project on its Integrations page, so each project can go to its own channel. The message carries the monitor name, why it is down, its project, its schedule and a link back to it, with a red, green or indigo bar for an outage, a recovery or a test.

A webhook alone sends nothing. Switch the channel on for each monitor on its Alerts tab, for going down, for recovering, or both. Then press Send a test alert to check it arrives.

Every channel is attempted for every alert, and each delivery is retried a few times with backoff, so a short outage at Resend, Slack or Discord does not lose a notification. A webhook that has been deleted, or whose channel was archived, is not retried. The test alert reports the error instead.

Treat a webhook URL like a password. Anyone who has it can post to the channel. If one leaks, delete it in Slack or Discord, create a new one and paste that in.

Get a Slack webhook URL

Slack gives out webhook URLs through a Slack app, which takes a minute to create. You only need one app, however many channels you post to.

Go to api.slack.com/apps and click Create New App, then From scratch. Name it Rippler, pick your workspace and click Create App.
In the app's settings, open Incoming Webhooks and switch Activate Incoming Webhooks on.
Click Add New Webhook at the bottom of the page, choose the channel the alerts should go to and click Allow.
Copy the new Webhook URL. It looks like https://hooks.slack.com/services/T…/B…/….
In Rippler, open the project's Integrations page, paste it under Slack and click Save.

To send another project to a different channel, go back to step 3 in the same app and add another webhook.

If your workspace requires approval to install apps, step 3 sends a request to a workspace admin instead. The webhook appears once they approve it.

Rippler only accepts https://hooks.slack.com/services/… URLs. A Workflow Builder webhook (https://hooks.slack.com/triggers/…) expects a message of a different shape, so every alert sent to one would fail. It is refused when you save.

Get a Discord webhook URL

You need the Manage Webhooks permission on the server.

Open Server Settings → Integrations → Webhooks and click New Webhook.
Give it a name, such as Rippler, and pick the channel the alerts should go to.
Click Copy Webhook URL. It looks like https://discord.com/api/webhooks/….
In Rippler, open the project's Integrations page, paste it under Discord and click Save.

An alert email states when the monitor entered the state, in the reader's own timezone, with the zone named in the message. Two members in different countries see the same outage in their own local time. Anyone without a zone set gets UTC, labelled as UTC.

Reminders

By default an outage is alerted on once. A monitor can be set to re-send its down alert every 1, 4, 8, 24 or 72 hours for as long as it stays down. Set it on the monitor's Alerts tab, under Sensitivity.

Reminders are for an outage nobody has picked up yet, for example one that arrived at 3am or into a channel nobody was watching.

Two things reminders do not do:

They never repeat an alert that was never sent. An outage still below its failure tolerance sends no reminders.
They stop as soon as the monitor recovers, without waiting for the next interval. The recovery alert is the last message.

Reduce noisy alerts

Pausing a noisy monitor stops the monitoring too. The right fix depends on why it is noisy:

Symptom	Fix
The job is fine but finishes later than expected	Raise the grace duration to a little above its longest normal run time.
The job genuinely fails sometimes and recovers on its next run	Raise failure tolerance, so it takes several failures in a row to alert.
You do not want this person emailed	Turn off alert emails on that person's profile.
The job is not supposed to run for a while	Pause the monitor. No pings expected, no alerts, and paused time is not counted against its uptime.
A known outage keeps re-alerting	Turn reminders back to "Only once", or fix the job. Reminders stop as soon as it recovers.

Raising failure tolerance only delays the alert. The monitor still shows as down in the app the whole time. A success resets the count, so two failures a week apart do not add up to one alert.

Missed runs count as failures too: with a tolerance of 3, a daily job that stops running entirely alerts on the third missed day.

On this page