Configuring Alerts

Overview

Alerts notify you when a monitor changes state. Typically when it goes down or recovers. Signalog supports eight alert channel types, and you can configure multiple channels per project so the right people get notified through the right tools.

Alert channels are separate from on-call paging. Channels are project-level routing for events (“send all alerts from this project to #ops on Slack”); on-call paging is user-level (“page me by SMS when I’m on-call”). They work together. A single incident might fire both a Slack channel alert and an SMS to the on-call person.

Creating an alert channel

Navigate to Settings > Alert Channels and click New Channel: select the channel type and fill in the required configuration.

Slack

1. Select Slack as the type.
2. Paste your Slack webhook URL (create one at api.slack.com/messaging/webhooks).
3. Optionally specify a channel name for display purposes.

Alerts include the monitor name, current state, response time, and a link to the monitor detail page. Slack interactive buttons let your team acknowledge incidents directly from the channel. No need to open Signalog.

Discord

1. Select Discord and paste a Discord webhook URL.
2. Create a webhook in your Discord server under Server Settings > Integrations > Webhooks.

PagerDuty

1. Select PagerDuty and enter your Integration Key (also called a routing key).
2. Create a new service in PagerDuty or use an existing one with an Events API v2 integration.

Signalog sends trigger events when monitors go down and resolve events on recovery, so PagerDuty incidents auto-resolve.

Opsgenie

1. Select Opsgenie and enter your API Key from an Opsgenie integration.
2. Signalog creates alerts on downtime and closes them on recovery.

Microsoft Teams

1. Select Teams and paste an incoming webhook URL.
2. Create the webhook in your Teams channel under Connectors > Incoming Webhook.

Email

1. Select Email and enter one or more email addresses (comma-separated).
2. Signalog sends HTML emails with monitor state details, response time, and direct links.

Web Push

1. Select Web Push: no configuration needed at the channel level.
2. Each user opts in from Profile → Notifications by clicking “Enable browser notifications”. The browser asks for permission, then subscribes them.
3. Once subscribed, alerts fire as native browser notifications even when the Signalog tab is closed.

Web push is available on every plan and works across Chrome, Firefox, Edge, and Safari.

Webhook

1. Select Webhook and enter your endpoint URL.
2. Signalog sends a POST request with a JSON payload on every state change.

The payload includes:

{
  "event": "monitor.state_change",
  "monitor": {
    "id": "mon_abc123",
    "name": "Production API",
    "url": "https://api.example.com/health",
    "current_state": "down",
    "previous_state": "up"
  },
  "check": {
    "status_code": 503,
    "response_time_ms": 12450,
    "checked_at": "2026-04-27T08:30:00Z"
  }
}

Webhook HMAC signing

To verify that webhook payloads genuinely come from Signalog, enable HMAC signing:

1. In the webhook channel settings, click Generate Signing Secret.

2. Signalog includes an X-Signalog-Signature header with each request:

   X-Signalog-Signature: t=1735689600,v1=hex_hmac_sha256

   Where t is the request timestamp (Unix seconds) and v1 is HMAC-SHA256(secret, "{t}.{body}") in hex.

3. On your server, compute the HMAC of the body and compare it with the header value. Verify t is within ~5 minutes of current time to prevent replay attacks.

Example verification (Node.js):

import { createHmac } from "crypto";

function verify(req, secret) {
  const sig = req.headers["x-signalog-signature"];
  const [tPart, vPart] = sig.split(",");
  const t = tPart.split("=")[1];
  const v1 = vPart.split("=")[1];
  const expected = createHmac("sha256", secret)
    .update(`${t}.${req.rawBody}`)
    .digest("hex");
  return v1 === expected && Math.abs(Date.now()/1000 - t) < 300;
}

Webhook signing is a Pro+ feature.

Webhook delivery logs and retry

Pro+ teams get a per-channel deliveries view showing every webhook delivery attempt with full request/response details. Failed deliveries can be retried with one click. See Webhook delivery logs for details.

Testing alerts

After creating a channel, click the Test button to send a sample alert. This confirms connectivity without waiting for an actual monitor state change.

For webhook channels, the test fires a payload with event: "test.fire" so you can wire up your endpoint to verify and respond differently to tests vs real events.

Per-monitor channel routing

By default, alerts fire all channels in the project. To restrict a monitor to specific channels:

1. Open the monitor detail page
2. Click Edit alert channels
3. Select which channels should fire for this monitor’s alerts

Useful for distinguishing critical-path Tier 1 alerts (page on-call + Slack) from Tier 3 informational alerts (Slack only).

Stakeholder vs alert channel routing

Alert channels fire on monitor state changes: they’re for engineers responding to incidents. Customer-facing communication uses the stakeholder notification flow on incident updates, which routes to status page subscribers (email + web push).

These two paths are separate and intentional. Engineers and customers don’t need the same updates.

Plan availability

Next steps

• Set up on-call schedules to route alerts to the right person
• Webhook delivery logs. Debug failed deliveries
• Configure escalation chains for unacknowledged alerts
• Stakeholder vs on-call notifications. Separate channels for separate audiences