Skip to navigation
Workspace

Alerts

Get told when calls fail, phones go unanswered or webhooks break, in the app, by email, in Slack or in PagerDuty.

Alerts watch your workspace and tell your admins when something goes wrong. Each kind of alert is a monitor. Every workspace starts with all monitors switched on at sensible thresholds, so you get useful alerts before you change anything.

You manage monitors on Developers → Alerts. Only admins and the owner can open it. See Members and roles.

The monitors

The Monitors list under Developers → Alerts, each with its threshold, Edit and a switch
Monitors under Developers → Alerts.

Most monitors are checked every five minutes. Event monitors fire as soon as the thing happens.

MonitorFires whenDefault
Conversation failuresA share of voice calls ended in an error20 % over 1 hour, at least 10 calls
Meeting join failuresA share of meetings the expert couldn’t get into30 % over 24 hours, at least 3 meetings
Tool failuresA share of tool calls made by experts failed (the Test button doesn’t count)25 % over 1 hour, at least 10 calls
Webhook delivery failuresA share of webhook deliveries whose latest attempt failed50 % over 1 hour, at least 10 deliveries
Webhook endpoint disabledAn endpoint was switched off automatically (15+ failures over 24 hours, or a 410 Gone)Event
API errorsA share of API-key and public API requests failed with a server error (5xx)10 % over 15 minutes, at least 20 requests
Monthly voice minutesVoice minutes this calendar month reached a number. Fires once a month1,000 minutes
Missed phone callsPhone calls rang but no expert answered1 or more in 15 minutes
Phone call failuresA share of phone calls failed30 % over 1 hour, at least 3 calls
Unanswered web callsA share of web and widget calls where no expert ever joined. Counted about an hour after the call closes50 % over 3 hours, at least 5 calls
Blocked visitor messagesA visitor’s message to a public expert was blocked by safety screeningEvent

Missed phone calls is Critical, because a caller heard silence. Monthly voice minutes is informational; the rest are warnings. Each alert says what happened and what to do first.

Tune a monitor

1

Open the monitor

Go to Developers → Alerts. Under Monitors, select Edit next to the one you want.

2

Set when it fires

  • Fire at: the threshold. For Monthly voice minutes it reads Fire when the month reaches.
  • Over the last: the window, from 15 minutes to 7 days.
  • Only with at least: the smallest number of samples in the window. This stops one failure out of two from paging anyone.
  • After firing, stay quiet for: a pause after it fires, so a monitor that keeps tripping tells you once per pause.
3

Choose who hears about it

Under Tell admins, tick In the app, By email, or both. With neither, the monitor still records incidents on the page but tells nobody.

4

Save

You’ll see Monitor saved. To stop a monitor completely, use the switch on its row.

Event monitors (Webhook endpoint disabled and Blocked visitor messages) have no threshold or window, only the Tell admins choice.

Incidents

When a monitor fires, it opens an incident: a red banner at the top of Developers → Alerts says what is firing and what to do, the monitor’s row shows Firing, and admins are told on the channels you picked. An incident resolves by itself when the numbers recover, or you can select Dismiss.

Blocked visitor messages works a little differently. Later blocks add to the open incident instead of opening new ones. It closes once an hour passes with no new block.

The Incidents list shows every incident, filtered by All, Active, Resolved or Dismissed. Incidents are kept for 90 days.

Service monitors on the same page show the health of Rydhm itself. You can’t change them, and Rydhm’s team is told when one fires.

Send alerts to Slack or PagerDuty

Besides the bell and email, admins can send every alert to Slack, PagerDuty or both. The setting covers the whole workspace.

1

Get the address from your tool

  • Slack: in Slack, go to Apps → Incoming Webhooks → Add to a channel, then copy the URL. It starts with https://hooks.slack.com/services/.
  • PagerDuty: on your service, go to Integrations, add Events API V2, and copy its integration key.
2

Connect it in Rydhm

Go to Settings → Integrations → Alert destinations. Select Connect next to Slack or PagerDuty, paste the value into Incoming webhook URL or Integration key (Events API v2), and save.

3

Send a test

Select Send test. A real message is posted, so you know it works before an incident needs it.

Every alert is sent with its severity: critical, warning or info. When the alert clears, Slack gets a “Resolved” message and the PagerDuty incident is resolved. Rydhm stores the webhook URL and the integration key encrypted, and shows them masked. Use Replace or Disconnect to change them.

Your own notifications

Settings → Notifications controls what reaches you: one row per kind of notification, with an In app switch and an Email switch. Each person chooses their own. Changes save at once.

NotificationWhoDefault
Meeting summary readyEveryoneIn app
Expert could not join a meetingEveryoneIn app and email
Alert triggeredAdminsIn app and email
Alert resolvedAdminsIn app
Webhook endpoint disabledAdminsIn app and email. Always on: you can’t turn it off

Members only see the rows meant for everyone.

  • Webhooks: get events in your own systems
  • Conversations: read the failed calls behind an alert
  • Phone: assign an expert to every number