Skip to main content
The Generic Webhook Alert Source lets Rootly ingest alerts from any tool that can fire HTTP webhooks. If your monitoring, observability, security, or data-quality platform can send a POST with a JSON body, Rootly can turn that event into an alert, route it to the right responder, and trigger downstream automation. Use it when your alerting tool doesn’t have a dedicated Rootly integration, when you’re ingesting alerts from custom or internal services, or when you want a single, unified pattern for handling webhook-based signals across multiple sources.

​
Compatible Alerting Tools

If a tool can send an HTTP POST with a JSON body, it works with Rootly. The Generic Webhook Alert Source is the standard way to wire up alerts from:
  • Application performance & error tracking — BugSnag, AppOptics, Coralogix
  • Infrastructure & log monitoring — Sumo Logic, Elastic, Chronosphere, Nagios, PRTG
  • Uptime & synthetic monitoring — Pingdom, StatusCake, uptime.com, Checkly, Cronitor, Runscope
  • Security & threat detection — CrowdStrike, Expel, Cloudflare
  • Data quality & observability — Monte Carlo
It also works for internal services, custom monitoring jobs, scheduled scripts, and any system you build in-house that needs to page an on-call responder. If your tool has a dedicated Rootly integration, prefer that — native sources reduce setup time and ship with vendor-specific field mappings. The Generic Webhook Alert Source is the right choice when no native integration exists.

​
How It Works

The Generic Webhook Alert Source gives you a webhook endpoint URL that your external system POSTs alert events to. When a request arrives, Rootly:
  1. Authenticates the request using the Bearer Token configured for the source.
  2. Parses the JSON body and extracts the fields you mapped — title, description, identifier, state, routing target.
  3. Creates or updates an alert based on the External Identifier. If Rootly already has an alert with the same identifier, follow-up events update it; otherwise a new alert is created.
  4. Routes the alert to the target you specified, either from the URL or from the payload itself.
  5. Triggers alert workflows, which can create incidents, page on-call, post to Slack, or run any other downstream action you’ve configured.
Webhook events are processed asynchronously. The POST returns quickly; the alert appears in Rootly shortly after.

​
Before You Begin

Before creating a Generic Webhook Alert Source, make sure you have:
  • Access to create alert sources in Rootly
  • A tool that can send POST requests with a JSON body
  • A plan for how alerts should be routed after ingestion
  • The fields you want Rootly to extract, such as:
    • Alert title
    • Description
    • External identifier
    • Alert state
    • Routing target
For best results, send requests with Content-Type: application/json. In production, the Generic Webhook Alert Source uses these endpoint patterns:
  • Base endpoint: POST https://webhooks.rootly.com/webhooks/incoming/generic_webhooks
  • Fixed target endpoint: POST https://webhooks.rootly.com/webhooks/incoming/generic_webhooks/notify/<type>/<id>
Use the base endpoint when routing will be determined from the incoming payload. Use the notify endpoint only when both the target type and target ID are included in the URL.

​
Installation

Create the Generic Webhook Alert Source

Go to the new alert source page and locate Generic Webhook Alert Source.
Generic Webhook Alert Source on the alert source page
You will be prompted to name the source.
Name your Generic Webhook Alert Source

Authenticate incoming requests

Rootly verifies inbound generic webhook requests using a Bearer Token — a static secret you provide in either of these forms:
  • Authorization: Bearer <secret>
  • secret as a query string or request parameter
If the secret is missing or invalid, Rootly rejects the request with a 401 Unauthorized response. Prefer the header form when your sending tool supports it — query parameters tend to be captured in proxy and load-balancer access logs.Example request (header form, recommended):
Example request (query-parameter form):

Map the incoming payload fields

Generic webhook sources do not require a strict vendor-specific payload shape. Instead, you configure how Rootly should interpret the incoming JSON by mapping fields from the webhook payload.At a minimum, you should map a field for the alert title so alerts are easy to identify in Rootly.Depending on your use case, you may also want to map:
  • Alert description
  • External URL
  • External identifier
  • Alert state
  • Notification target type
  • Notification target ID
Follow the instructions shown on the Generic Webhook creation page to configure these mappings.
Notification target ID must be Rootly’s internal resource ID — not a team name, service slug, or any human-readable identifier. Open the service, team, or escalation policy in Rootly and copy the ID from its edit page. Using a name or slug is a common cause of alerts that ingest successfully but never route. See Route By Payload for the full mapping guidance.

​
Authentication

Rootly authenticates inbound webhook requests with a Bearer Token — a static secret sent in the Authorization header, or as a secret query string parameter on the webhook URL. Prefer the header form when your sending tool supports it — query parameters tend to be captured in proxy and load-balancer access logs, so they’re more exposure-prone than a header. Either form is simple to set up: paste the secret into your sending tool and you’re done. Code samples for Bearer Token authentication live in Installation.

​
Mapping Payload Fields

Rootly doesn’t require a specific JSON shape. You map fields from your sending tool’s payload to Rootly’s alert fields during source creation. A typical payload from a monitoring tool:
Map those fields to Rootly’s alert fields in the source configuration: The External Identifier is what Rootly uses to match recovery events back to the original alert when auto-resolution is configured. Map it to whatever field your sending tool uses as the alert’s persistent ID (monitor_id, incident_id, alert_uuid, etc.) so that a follow-up “resolved” event can close the original alert instead of being ignored. See the Installation guide for the field-mapping UI walkthrough.

​
Routing Alerts

There are two ways to tell Rootly where an alert should go. You can mix both across sources, but a single source typically uses one or the other.

Route By URL

Include the target type and ID directly in the webhook URL Rootly generates:
Use this when every alert from this source should always route to the same target — one service, one team, or one escalation policy. Cleanest setup, and you do not need to map the target type and target ID in the payload mapping step.
Webhook URL configuration with notification target

Route By Payload

Send the target type and ID in the JSON body and let Rootly extract them via field mappings:
The notification_target_id is the Rootly resource’s internal ID — open the service, team, or escalation policy in Rootly and copy the ID from its edit page. Names and slugs aren’t accepted in this field.Use this when a single source needs to route alerts to different targets depending on the event — useful when your monitoring tool already tags events by service or team, or when you want the routing decision to come from the event payload itself. Advanced payloads can also include a Rootly notification target object directly in the JSON body.
Common target types: service, group (or team), escalationPolicy.

​
Automatically Added Labels

Every alert ingested from a Generic Webhook Alert Source is automatically tagged with a source_name label whose value is your alert source’s name parameterized — lowercased, with spaces and other non-alphanumeric characters replaced by hyphens. For example, an alert source named Harbor Image Scan (c1) adds source_name:harbor-image-scan-c1 to every alert it produces. This label is the canonical way to differentiate alert sources of the same type in Alert Workflows. The source condition in a workflow matches by source type (for example, generic_webhook), so if you have multiple Generic Webhook sources, the workflow can’t tell them apart from the source condition alone — pair it with a source_name label condition (using contains any of) to scope each workflow to a specific source instance. See Scoping to a specific source instance for the workflow-side setup.

​
Test the Source

Send a test alert

After setup, send a test alert from your observability provider and confirm that Rootly receives and processes it as expected.
Testing a Generic Webhook Alert Source

Confirm the alert was processed correctly

A successful test should confirm that:
  • The webhook request reaches Rootly
  • The payload is parsed correctly
  • The alert title and other mapped fields are populated as expected
  • The alert routes to the correct target
  • The alert appears in Rootly
Rootly processes webhook events asynchronously, so the alert may appear shortly after a successful request.If the request is authenticated correctly but the payload is missing expected fields, Rootly may still ingest the event, but the alert may not contain the data you intended.

​
Auto-Resolution

Auto-resolution lets Rootly close alerts when your external system sends a recovery or resolved-style webhook event. This is useful when your monitoring platform sends one event when an issue starts and another when it clears — by configuring the correct identifier and state fields, Rootly recognises the related alert and applies the resolution logic you defined. Auto-resolution depends on the resolution configuration stored on the source. For the Generic Webhook Alert Source, that configuration is based on:
  • The field that identifies the alert
  • The field that represents its state
  • The value that should be treated as resolved
These settings allow Rootly to handle follow-up webhook events consistently when your source sends a recovery or cleared event.

​
Configure Auto-Resolution

Map the identifier field

Configure a field mapping for the external identifier in your webhook payload.This value should stay consistent across events for the same alert so Rootly can associate follow-up webhook events with the correct alert.

Map the state field

Configure a field mapping for the alert state in your webhook payload.This field should represent whether the alert is active, cleared, resolved, or in another lifecycle state used by your source system.

Define the resolved state value

Set the state value that Rootly should treat as resolved.In most cases, this is an exact match against the value you configure, such as resolved, recovered, or ok.

Enable auto-resolution

Turn on auto-resolution for the Generic Webhook Alert Source after your identifier and state mappings are configured.Once enabled, Rootly uses those mappings and the resolved-state value as part of the source’s resolution configuration.

​
Important Notes

  • Auto-resolution depends on the field mappings configured for the source
  • The identifier field and state field should be stable and predictable in your incoming webhook payload
  • If your payload does not include the expected values, Rootly may still ingest the alert event, but it may not resolve the alert the way you intend
  • Some teams may also use payload-driven alert status fields separately from auto-resolution mapping
  • Teams using newer alert field or resolution-rule configuration may manage this behavior through that newer configuration path instead of the legacy generic webhook mapping flow

​
From Alert to Incident

Alerts created through this source behave like any other Rootly alert — they’re regular signals you can drive any of Rootly’s alert-driven automation off of:
  • Create incidents automatically based on alert content, severity, or service
  • Page on-call responders through escalation policies
  • Post notifications to Slack, Microsoft Teams, or email
  • Trigger downstream workflows that update runbooks, status pages, ticketing systems, or run custom scripts
The webhook source ingests the alert; alert workflows decide what the alert means and what should happen next.

​
Troubleshooting

The most common cause is a missing or mismatched Bearer token. Confirm:
  • The Authorization: Bearer <secret> header is present on the request (or the secret query string parameter is set)
  • The secret matches the one shown in the source configuration in Rootly
Webhooks process asynchronously, so check again after a few seconds. If the alert still doesn’t appear:
  • Verify the Title field mapping points at a non-empty field in the payload
  • Check the source’s recent activity in Rootly to confirm the payload was received
  • Confirm the routing target referenced in the URL or payload exists and isn’t archived
The field mapping is pointing at JSON paths that don’t exist in the incoming payload. Capture a real payload using a request inspector (RequestBin, webhook.site, or a local server), compare it against your mapping, and update the JSON paths to match the actual structure.
The External Identifier isn’t mapped to a stable, unique value, so the resolved event can’t be matched back to the original alert. Map it to whatever field your sending tool uses as the persistent ID (monitor_id, incident_id, alert_uuid, etc.) so trigger and recovery events share the same identifier.
Either the recovery payload has a different External Identifier than the original alert, or the State field isn’t mapping to the exact resolved value you configured. See Auto-Resolution for the matching rules.
Switch from URL-based routing to payload-based routing. Map the target type and target ID fields from the incoming JSON so the routing decision lives in the event itself.

​
Frequently Asked Questions

No. If your tool can send an HTTP POST with a JSON body, the Generic Webhook Alert Source can ingest its alerts. Native integrations are nicer when they exist because they ship with vendor-specific field mappings and reduce setup time, but they’re not required.
Alerts are signals — discrete events from your monitoring stack. Incidents are coordinated response — the incident channel, the timeline, the retrospective. One incident may be informed by many alerts. The webhook source creates alerts; alert workflows decide when an alert should escalate to an incident.
You can, but it’s cleaner to create one source per sending tool. Separate sources make it easier to route alerts differently per tool, attribute issues during troubleshooting, and manage authentication independently.
Route the alert to a single target with the webhook, then use an alert workflow to fan out the response — page on-call, post to Slack, create an incident, update a status page. The webhook ingests the alert; the workflow decides what should happen next.
Both work. Rootly accepts the Bearer secret either as the Authorization: Bearer <secret> header or as a secret query string parameter on the webhook URL.
The webhook source maps from existing payload fields, and alert workflows fire after an alert is created and routed — not before. To compose a richer title (combining service name, severity, and a summary, for example), construct the title in your sending system before the webhook is sent and map the prepared field as the Title.
Any valid JSON. Rootly doesn’t require a specific schema — instead you map your tool’s existing fields to Rootly’s alert fields during source setup. Most monitoring tools work out of the box; you just point them at the webhook URL and configure the mapping.