Skip to main content
The Generic Webhook Alert Source lets Rootly ingest alerts from tools that do not have a dedicated Rootly integration. This is a strong option when your monitoring or observability platform can send webhook events, but does not have a native Rootly connector. Instead of requiring a strict vendor-specific payload format, Rootly gives you a flexible way to accept incoming alert data and map it into alerts. With the Generic Webhook Alert Source, you can:
  • Accept alerts from virtually any tool that can send webhooks
  • Map incoming payload data to the alert fields Rootly uses
  • Route alerts to services, teams, escalation policies, users, or other supported targets
  • Automatically resolve alerts when your source sends a recovery or cleared event, when auto-resolution is configured
  • Use alert workflows to create incidents and automate follow-up actions

​
Before You Begin

Before setting up a Generic Webhook Alert Source, make sure you have:
  • Access to create and configure alert sources in Rootly
  • A system that can send HTTP webhook requests, typically as a POST request with a JSON body
  • The alert data you want to map, such as title, description, identifier, routing target, or alert state
  • A clear plan for how alerts should be routed, resolved, and automated after ingestion
If you want to automate incident creation or other follow-up actions, make sure you also understand how your alert workflows should behave once alerts are received.

​
How It Works

The Generic Webhook Alert Source gives Rootly a webhook endpoint that your external system can call when an alert is triggered or resolved. Once Rootly receives the payload, it evaluates the fields you mapped for that source and uses them to:
  • Create or update an alert
  • Route the alert to the appropriate target
  • Trigger alert workflows and downstream automation
This makes the Generic Webhook Alert Source a flexible bridge between Rootly and any alert-producing system that can send webhook requests.

​
Authentication

Rootly supports two authentication methods for generic webhook sources:
  • Bearer Token (default) — a static secret sent in the Authorization header or as a query parameter. Simple to set up and suitable for most use cases.
  • HMAC Signature — the sender signs the request body with a shared secret, and Rootly verifies the X-Webhook-Signature-256 header using a timing-safe comparison. This provides stronger security because the signing secret never travels over the wire.
When using HMAC, the Bearer token is still required for source identification. HMAC adds an additional verification layer on top. See the Installation guide for detailed setup instructions for both methods.

​
Installation

To set up the Generic Webhook Alert Source, create the source in Rootly, copy the generated webhook URL, and configure your external system to send alert events to that endpoint. During setup, you can define how Rootly should interpret the incoming payload by mapping fields such as the alert title, description, identifiers, routing target, and resolution state.

​
Auto-Resolution

The Generic Webhook Alert Source can automatically resolve alerts when your external system sends a recovery or resolved event. To do this, Rootly compares the incoming event against the identifier and resolution rules configured for the source. This allows Rootly to match follow-up webhook events to the correct alert and update its status accordingly.

​
Workflows

Alerts created through the Generic Webhook Alert Source work like any other alert in Rootly and can be used with alert workflows. That means you can automate actions such as:
  • Creating incidents
  • Sending notifications
  • Triggering routing and escalation flows
  • Running custom follow-up automation

Installation

Configure the webhook endpoint, authentication, and field mappings.

Auto-Resolution

Learn how Rootly matches recovery events and resolves alerts automatically.

Alert Workflows

Automate incidents, notifications, routing, and other alert-driven actions.