Integrations

Webhook Receivers

Overview

Not every service you depend on has a public status page. Webhook receivers let external services push status updates directly to Alert24 via HTTP POST requests. When Alert24 receives an update, it automatically changes your service status, updates your status page, tracks SLA, and notifies your team — just like a status page check would.

This is useful for:

  • Services without status pages — Internal tools, smaller SaaS providers, or custom infrastructure
  • Your own services — Push status from your CI/CD pipeline, health checks, or monitoring tools
  • Alert24-powered status pages — If a service you depend on uses Alert24 for their status page, they can push updates directly to you

How It Works

  1. Create a service in Alert24
  2. Copy the webhook URL from the service page
  3. Paste the URL into your monitoring tool, CI/CD pipeline, or any external service
  4. Alert24 automatically detects which tool sent the webhook and applies the correct parsing — no configuration needed

Auto-Detection

When a webhook arrives, Alert24 automatically identifies which tool sent it — no manual configuration required.

How it works

  • Alert24 checks HTTP headers and payload structure against 120+ known tool signatures
  • If a match is found, Alert24 automatically applies the correct status field path, status mapping, and message extraction
  • The detection result is cached so subsequent webhooks from the same tool are processed instantly
  • If no match is found, Alert24 falls back to looking for a standard status field in the JSON payload
  • Auto-detection is transparent — you can see which tool was detected in the webhook delivery logs

Pre-Built Integration Templates

Alert24 includes 120+ pre-built webhook receiver templates for popular tools across multiple categories.

With auto-detection, you don't need to manually select a template. Just paste the webhook URL into your tool and Alert24 figures out the rest. Templates are still available in Settings > Integrations if you want to browse the full list or customize the configuration.

Template Categories

  • Monitoring & Observability — Datadog, Prometheus/Alertmanager, Grafana, New Relic, Sentry, Pingdom, UptimeRobot, Zabbix, Nagios, Dynatrace, Splunk, Better Stack, Checkly, Honeycomb, and more
  • Cloud Providers — AWS CloudWatch, AWS SNS, AWS EventBridge, Azure Monitor, Azure DevOps, Google Cloud Monitoring, Google Cloud Build, Linode, DigitalOcean
  • CI/CD — GitHub Actions, GitLab CI, Jenkins, CircleCI, Travis CI, ArgoCD, Buildkite, Semaphore, Drone, Codefresh
  • Logging — ELK Stack, Splunk, Sumo Logic, Graylog, Loggly, Datadog Logs, Coralogix, Axiom, Mezmo
  • ITSM & Ticketing — Jira, ServiceNow, Freshservice, Zendesk, Opsgenie, xMatters, VictorOps
  • Messaging — Slack, Microsoft Teams, Discord, Telegram, Mattermost, Google Chat, Webex
  • Security — Wiz, CrowdStrike, Snyk, Trivy, Lacework, Falco, Qualys, Tenable
  • Custom — Generic JSON, XML, and form-encoded webhook receivers

Using a Template

  1. Go to Settings > Integrations
  2. Browse or search the template library
  3. Select a template (e.g., "Datadog")
  4. Alert24 pre-configures the status field path, status mapping, and payload parsing for that tool
  5. Copy the webhook URL and add it to the external tool

Templates include auto-incident creation and resolution rules tuned for each tool's payload format.

Custom Integrations

For tools not in the 120+ supported list, there are three ways to integrate with Alert24:

Option A: Standard format

Any tool that sends JSON with a status field works out of the box:

{ "status": "down", "message": "Service unavailable" }

Option B: Custom field mapping

If your tool uses a different payload structure, expand the Custom Configuration section on the service page:

  • Set a custom status field path (dot notation, e.g., data.attributes.status)
  • Set a custom message field path
  • Define custom status value mappings
  • Once custom config is saved, auto-detection is disabled for that receiver

Option C: Generic webhook

For tools that don't send status values at all, use Alert24's API to update service status directly:

curl -X POST https://app.alert24.net/api/webhooks/incoming/<token> \
  -H "Content-Type: application/json" \
  -d '{"status": "degraded", "message": "High latency detected"}'

Setting Up a Webhook Receiver

The webhook URL is available directly on the service page. The recommended flow:

  1. Go to your service page
  2. Copy the webhook URL shown in the Webhook Integration section
  3. Paste it into your external tool
  4. Done — Alert24 handles the rest

You can also create webhook receivers from Settings > Webhook Receivers if you need to configure HMAC signature verification or other advanced options.

Payload Format

The simplest payload Alert24 accepts:

{
  "status": "degraded",
  "message": "Email delivery delays in US-East region"
}

Alert24 extracts the status value and maps it to a service status. The message field is used for status page updates.

Nested Payloads

If the external service sends a more complex payload, configure the Status Field with dot notation to tell Alert24 where to find the status:

Status Field: data.attributes.current_status

{
  "data": {
    "attributes": {
      "current_status": "major",
      "description": "Database connectivity issues"
    }
  }
}

Dynamic Service Matching

Instead of linking a receiver to a fixed service, you can configure a Service Name Field to match the service by name from the payload. This lets a single receiver update multiple services:

{
  "service_name": "API Gateway",
  "status": "down",
  "message": "API Gateway is unreachable"
}

Status Mapping

Alert24 maps incoming status strings to service statuses. The default mapping covers common conventions:

Alert24 Status Accepted Values
Operational operational, up, ok, healthy, none, resolved
Degraded degraded, partial, warning, minor
Down down, outage, major, critical, error
Maintenance maintenance, scheduled, under_maintenance

Matching is case-insensitive. You can customize the mapping to match any naming convention your external service uses.

Security

HMAC Signature Verification

For production use, set an HMAC secret on your receiver. The sending service must include a signature header computed as HMAC-SHA256(request_body, secret).

Alert24 verifies the signature before processing the payload. If verification fails, the request is rejected with a 401 status and logged as an authentication failure.

The signature header name is configurable (default: X-Webhook-Signature).

Token-Based Authentication

Every webhook receiver has a unique 64-character token embedded in its URL. Even without HMAC verification, this token provides a baseline level of security — the URL is unguessable and specific to your receiver.

Automatic Incident Management

Webhook receivers can automatically create and resolve incidents:

  • Auto-create incidents — When the service goes down or degraded, an incident is created with your chosen severity level
  • Auto-resolve incidents — When the service returns to operational, open incidents created by this receiver are automatically resolved

What Happens on Status Change

When a webhook receiver updates a service's status, the full Alert24 pipeline runs:

  1. Service status updates on your dashboard
  2. SLA tracking records the status change for uptime calculations
  3. Status page updates — A post is added to your public status page
  4. Alert rules evaluate — Application-level alerts fire if configured
  5. Team notifications — Your on-call team is notified through configured channels
  6. Incidents — Auto-created/resolved if enabled

Delivery Logs

Every incoming webhook is logged with the source IP, payload, processing result, and any errors. View the last 50 deliveries for each receiver to debug integration issues.

Log entries show:

  • Whether the webhook was processed, ignored (no status change), failed (bad payload), or auth_failed (bad signature)
  • The raw status value extracted from the payload
  • The mapped Alert24 status
  • The previous and new service status

Use Cases

Monitoring services without status pages

Services like Pushmail, Simli, or internal tools don't have public status pages. Set up a webhook receiver and push status changes from your own monitoring checks (HTTP checks, synthetic tests, etc.).

Connecting Alert24 status pages

If a service you depend on publishes their status page on Alert24, they can configure an outbound webhook to push updates directly to your webhook receiver — giving you real-time, push-based status updates instead of polling.

CI/CD pipeline integration

Push deployment status from your CI/CD pipeline. Mark a service as "maintenance" when a deploy starts and "operational" when it completes.

# Mark service as maintenance before deploy
curl -X POST https://alert24.net/api/webhooks/incoming/<token> \
  -H "Content-Type: application/json" \
  -d '{"status": "maintenance", "message": "Deploying v2.4.1"}'

# Mark operational after deploy
curl -X POST https://alert24.net/api/webhooks/incoming/<token> \
  -H "Content-Type: application/json" \
  -d '{"status": "operational", "message": "Deploy v2.4.1 complete"}'

Custom health check integration

If you run your own health check infrastructure, push results to Alert24 instead of building a separate status dashboard.

← Supported ProvidersCloudflare Integration →