Alerts

launchroom watches your services, servers, certificates and backups. It notifies you when something needs attention and again when the problem is resolved. Rules are built in and on by default, so the only setup is choosing where alerts go.

Set up notificationsCopy Anchor Link

Open Settings → Notifications. Without a destination yet, the page asks "Where should we tell you?" with four choices: Email, Slack, Discord and Webhook. Fill in the field for that kind and press Send a test. The result appears on the page.

Owners and admins can change notifications. Every team member can see them.

Built-in rulesCopy Anchor Link

SeverityCopy Anchor Link

Alerts are either warning or critical:

• Failed deploys and crashing services are critical in production and warnings elsewhere.
• Offline servers and failed backups are always critical.
• A disk at 95 % or more, an error rate of 25 % or more, and a certificate with less than 3 days left (or already expired) become critical.
• High CPU and memory are warnings.

ThresholdsCopy Anchor Link

Under What we tell you about, each rule has a switch. Rules with a threshold read as a sentence with number fields, for example "CPU above 90 % for 10 min". Save with the bar that appears at the bottom.

Thresholds apply to the whole team.

ChannelsCopy Anchor Link

Each channel can receive everything from warning up, or critical only. You can pause, edit and remove channels. Each row shows when it last delivered or why it failed.

Email uses your launchroom's mail settings. If no mailer is configured, the Notifications page says so.

Webhook URLs and signing secrets are stored encrypted and never shown again in full. The page shows only the host and the last four characters. Outgoing requests go to public addresses only, never to private networks or the control plane itself, and don't follow redirects.

When you hear from launchroomCopy Anchor Link

• Once per problem: while a problem lasts, the alert stays open and you get one message for it.
• Repeats: only for new occurrences, such as another failed deploy of the same service after 10 minutes or another failed backup after 6 hours. Condition rules (CPU, disk, offline) never repeat.
• Resolved messages: when the problem is gone, every channel that was notified gets one "resolved" message. Alerts that were never sent resolve without a message.
• Cooldown: if the same problem comes back within 10 minutes of resolving, the old alert reopens instead of a new one. You're notified again only if the last message is older than 10 minutes, so a flapping service doesn't flood your channel.

Alerts also appear on the Activity page (filter Alerts) with how long they were open, and project activity shows the project's alerts.

Backup alertsCopy Anchor Link

"A backup fails" covers database backups, volume backups and the backup of launchroom itself. The alert names the database or volume and the destination, and resolves on its own after the next successful backup. See Backups and Troubleshooting backups.

Signed webhooksCopy Anchor Link

A webhook channel receives a POST with Content-Type: application/json:

{
  "type": "alert.fired",
  "id": "alr_01J…",
  "rule": "deploy_failed",
  "severity": "critical",
  "status": "firing",
  "title": "web failed to deploy",
  "summary": "…",
  "url": "https://launchroom.example.com/p/…",
  "team": { "id": "team_…", "name": "Acme" },
  "project": { "id": "prj_…", "name": "shop" },
  "environment": { "id": "env_…", "name": "production" },
  "service": { "id": "svc_…", "name": "web" },
  "server": null,
  "facts": { "Commit": "3b7d5e1" },
  "openedAt": "…",
  "resolvedAt": null,
  "sentAt": "…"
}

type is alert.fired, alert.repeated, alert.resolved or alert.test. Headers:

The signing secret (it starts with lrwh_) is shown once when you create the channel. You can rotate it later.

Verify the signatureCopy Anchor Link

The signature is an HMAC-SHA256 keyed with the signing secret, computed over the timestamp, a dot and the raw request body: <t>.<body>. To verify:

1. Read the raw body before parsing it as JSON.
2. Split the header into t and v1.
3. Reject the request if t is more than 5 minutes old.
4. Compute the HMAC of t + "." + body and compare it with v1 in constant time.

import crypto from 'node:crypto';

export function verify(rawBody, header, secret) {
  const parts = Object.fromEntries(header.split(',').map((p) => p.split('=')));
  const t = Number(parts.t);
  if (!t || Math.abs(Date.now() / 1000 - t) > 300) return false;
  const expected = crypto
    .createHmac('sha256', secret)
    .update(`${parts.t}.${rawBody}`)
    .digest('hex');
  const a = Buffer.from(expected);
  const b = Buffer.from(parts.v1 ?? '');
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

Answer with any 2xx status to confirm delivery. A failed delivery is tried up to three times in total, a few minutes apart, and the failure is recorded on the channel. Failed deliveries don't change the alert itself.

To reach a paging tool, point the generic webhook at a small receiver that forwards to your on-call system.