Getting paged in Slack before a customer notices, not after

The gap between “something broke” and “someone found out” is where an incident actually gets expensive — not the failure itself, the delay before a human knows about it. A notification rule closes that gap for the dozen or so events that actually warrant interrupting someone.

What a rule actually is

One channel — a Slack incoming webhook, any webhook URL that takes a JSON POST, or an email address — scoped to either every app on the team or one specific app, with a tick-list of which events should reach it. Every new team starts with one rule already configured, not an empty settings page: an email to the team owner covering deploy failures, offline servers, crash loops, and apps down, editable or deletable like any other rule once you’ve set up something better suited to your team.

The actual event list

Team-wide rules cover deploy failure/success, a deploy waiting for approval, a server going offline, a crash loop, a server running low on disk/CPU/memory, an app failing its uptime checks or a certificate nearing expiry, new cost waste or a budget forecast going over (tied to Costs and savings), a saved log search matching too often, a job backlog building up and clearing, a metric alert firing and resolving, and maintenance windows or long-running data jobs finishing.

That’s most of what a small team would otherwise wire up across three or four separate tools — a status page’s own alerting, a log-alerting SaaS, a cost-anomaly tool — as one list in one place, each event independently toggleable per channel.

Scoped to one app when that’s all that matters

Settings → General → Notifications on a specific app adds a rule just for it — deploy failed/succeeded, app down, crash loop, job backlog, metric alerts, data job completions. For a team running several apps where only one is actually critical, this is the difference between a notification channel people actually read and one that gets muted after the third irrelevant alert about a side project.

What a webhook rule actually sends

A real JSON POST, not a vague “something happened” ping — a metric alert payload carries event: "metric_alert", status (firing or resolved), the metric, value and threshold that triggered it, and deploy events include the deploy’s own note. Enough structure to route into whatever a team already uses for on-call, without screen-scraping a Slack message to figure out what actually happened.

Separately, Team → Webhooks handles signed outbound webhooks meant for your own systems to consume programmatically — a different mechanism from notification rules, worth knowing apart since the two solve adjacent but distinct problems (alerting a human vs. integrating a system).

What’s honestly still beta

Email delivery depends on email sending being configured on Railyard’s own side, and is marked beta for exactly that reason — anything actually depended on should also have a Slack or webhook rule as a second channel, not email alone. Each rule has one destination; two Slack channels means two rules, not one rule with two targets. Both are small, specific limits stated plainly rather than discovered the day an email alert silently didn’t arrive.

Full reference: Notifications.