Webhooks

When a service can send a webhook but can’t be taught Pocketbell’s API, make a webhook Source in the app. It gets its own URL:

https://api.pocketbell.dev/v1/hooks/pbw_…

Paste it wherever the service asks for a webhook URL. The URL is the secret: keep it private, and replace it in the app if it leaks.

What it accepts

A POST of up to 64 KB, as JSON, a form (application/x-www-form-urlencoded) or plain text. There is nothing to sign and no key to send.

Tools Pocketbell knows

Events from these tools need no template and no rules: Pocketbell reads their own fields and writes the notification as a person would, with the priority already set. The all-clear doesn’t replace the alert: both stay in the inbox, in order, and the all-clear stops the alert repeating and says how long it lasted.

Tool	Down or firing	Back up or resolved
Uptime Kuma	“API is down”, its reason, Critical, a button to the site	“API is back up”, “Down for 12 min”, the result and response time
Grafana	“High CPU is firing”, the alert’s summary, Critical, a button to Grafana	“High CPU resolved”, “Firing for 12 min”
Alertmanager	“DiskFull is firing”, the summary, Critical for severity critical, else Important	“DiskFull resolved”, “Firing for 12 min”
Healthchecks.io (the guide’s body)	“Backups is down”, Critical	“Backups is back up”, “Down for 12 min”

Anything you set wins, part by part: your own title or message template replaces the text, a priority rule or a default priority other than Normal the priority, and a replace rule makes the all-clear replace the alert instead. The Source’s setup shows what each event becomes, with Customize… to write your own; until you do, its Notification Content says Automatic.

Templates

With no template, and from a tool not listed above, the notification reads as a summary of the event’s top-level fields: status: down · server: api-2.

Set a title and message template in the app to choose the words yourself. A {{field}} is replaced with that field’s value, and dots reach inside objects and lists:

Template	Event	Result
{{check.name}} is {{status}}	{"check": {"name": "api-2"}, "status": "down"}	api-2 is down
First item: {{items.0.id}}	{"items": [{"id": "A-17"}]}	First item: A-17

A field that isn’t there is left empty. There are no expressions or logic: a field is there, or it isn’t.

While you set up the Source, the app shows the latest event it received and a live preview of the notification, so send one test event first.

Priority and replacing

Most services send every event to one URL and say what happened in a field, like status. Two optional rules, in the same place as the templates, act on that field:

• Priority: pick the field, then a priority for each value you care about. down → Critical, up → Normal. Any other value, or an event without the field, arrives at the Source’s default priority. The first listed value that matches wins. Values are compared as text, ignoring case and spaces at the ends, so a number or true matches as it’s written (0 matches Uptime Kuma’s numeric heartbeat.status).
• Replace: pick the field that names the thing, like a check or monitor ID. A new notification with the same value takes the earlier one’s place on the Lock Screen and at the top of the inbox. The earlier one stays in its history, with when it came and how long it lasted, so you can see how long something was down. If it was a Critical notification, its repeats stop. Give the recovery Quiet to clear it without a sound: a Silent one shows nothing, so the alert leaves the screen only when the app next syncs.

Event	Rules	Arrives as
{"status": "down", "check": "c1"}	down → Critical, replace by check	Critical, repeating until acknowledged, for up to an hour
{"status": "up", "check": "c1"}	up → Normal, replace by check	Normal: it takes the Critical notification’s place and stops its repeats, and shows how long c1 was down
{"status": "degraded", "check": "c2"}	no row for degraded	The Source’s default priority

Suggest from This Event fills both rules when the event’s state is in a usual field (status, state, alertstate, conclusion, heartbeat.status, alerts.0.status and a few more). Change anything before you save.

A Critical notification from a rule is like any other: it repeats every five minutes until acknowledged, for up to an hour, and at most 10 repeat at once per account. The rules apply to events that arrive after you save them.

Retries

Send an Idempotency-Key header, if the service can, and a retried delivery of the same event won’t notify you twice.