Skip to main content

​
Overview

Chronosphere’s notification policies fan monitor alerts out to wherever they need to go. Point one of those webhooks at Rootly and every triggering monitor becomes a normalized alert that can page on-call, route to a service, or auto-create a full incident through alert workflows. Alertmanager-style batches arrive as a single Rootly alert, fingerprint-keyed so duplicates don’t pile up. Chronosphere has first-class support as a dedicated alert source in Rootly — you don’t need the Generic Webhook source. The integration ships with vendor-specific Alertmanager payload parsing, fingerprint-based deduplication via UUID v5, and a guided setup wizard in the Rootly dashboard.

Page On-Call

Fire escalation policies the moment a Chronosphere monitor triggers, paging the right responder in seconds.

Auto-Create Incidents

Turn a monitor alert into a full Rootly incident with custom fields, workflows, and Slack channels.

Multi-Alert Grouping

Chronosphere’s Alertmanager-style batches collapse into a single Rootly alert, keyed on the sorted fingerprint set.

Per-Monitor Routing

Send infrastructure alerts to one team and application alerts to another, all from a single Chronosphere notification policy.

​
Before You Begin

You’ll need access to both sides of the connection.
  • In Rootly — the On-Call Admin or On-Call User role so you can create alert sources. See Schedule Permissions.
  • In Chronosphere — permission to create notifiers and notification policies (typically Admin or a custom role with notifier write access).
A clear routing plan helps too: decide whether every alert from this Chronosphere notifier should land on the same service or team, or whether routing varies per monitor.

​
Add the Alert Source in Rootly

The Rootly side hands you a webhook URL with the authentication secret baked into the query string. Paste that URL into Chronosphere in the next section.
1

Open Alerts → Sources

In the Rootly dashboard, navigate to Alerts → Sources and click New alert source.
2

Choose Chronosphere

Select Chronosphere from the list of available sources and give the source a descriptive name — for example, Chronosphere — Production Monitors.
3

Set The Default Routing Target (Optional)

If every alert from this source should always route to the same service, team, or escalation policy, set the target on the source configuration page. Leave it blank if you want routing to vary per Chronosphere notification policy — covered under Routing Alerts.
4

Copy The Webhook URL

Rootly generates a unique webhook URL with the per-source secret embedded as a query parameter. Copy the full URL — that’s what goes into Chronosphere.Without a default routing target:
With a default routing target baked into the URL:

​
Configure the Webhook in Chronosphere

Create a webhook notifier in Chronosphere, point it at the Rootly URL, then attach it to a notification policy.
1

Create A Webhook Notifier

In Chronosphere, navigate to Alerts → Notifiers and click Create notifier. Choose Webhook as the type. For the latest Chronosphere UI specifics, refer to Chronosphere’s webhook notifier documentation.
2

Set The Webhook URL

Paste the full webhook URL you copied from Rootly into the URL field, including the ?secret=... query string. The method is POST.
Rootly’s Chronosphere source authenticates the request using the secret query parameter — not Bearer Token or HMAC. The secret has to remain on the URL, so treat the full webhook URL as a credential.
3

Configure Resolved Notifications (Optional)

Chronosphere’s webhook notifier has a Notify when resolved toggle. Leaving it off is recommended for the Rootly source — resolved events are not used to close alerts in Rootly (covered in Handling Resolved Events below).
4

Attach The Notifier To A Notification Policy

Save the notifier, then open or create a Notification Policy in Chronosphere. Add a rule that routes the monitors you care about to the new Rootly notifier. New triggers on those monitors POST to the Rootly webhook URL within seconds.
Chronosphere optionally signs webhooks with HMAC-SHA256 via the Chronosphere-Webhook-Timestamp header. Rootly’s Chronosphere source doesn’t verify that signature — authentication relies on the secret query parameter instead. You can leave Chronosphere’s signing toggle off without affecting the integration.

​
Payload Reference

Rootly’s Chronosphere source parses the Alertmanager-style payload Chronosphere sends. The full raw payload is preserved on the alert record, so any field Chronosphere sends remains accessible to alert routes, workflows, and field mappings.
​
string
The monitor’s alert name from Chronosphere’s common labels. Populates the Rootly alert’s summary. Defaults to "Alert from Chronosphere" if absent.
​
array
required
Array of one or more alert objects. Each contains at minimum a fingerprint and a startsAt timestamp.
​
string
required
Chronosphere’s stable identifier for each individual alert. Rootly combines all fingerprints from a single webhook (sorted, comma-joined, UUID v5 hashed) into the External Identifier for deduplication.
​
ISO 8601 datetime
When the first alert in the batch began firing. Populates the Rootly alert’s started-at timestamp.
​
URL
Direct link back to the Chronosphere alert view. Preserved on the alert record for responders to jump straight to the source.
​
string
Either firing or resolved. See Handling Resolved Events for behavior differences.
​
object
Optional. Sets the routing target for this specific webhook. Used only when the alert source does not have a default URL-based target — if a URL target is configured on the source, it takes precedence. Expects type (Service, Group, or EscalationPolicy) and id (the Rootly resource’s internal ID).

​
Routing Alerts

Two ways to point a Chronosphere alert at the right responder. URL-based routing takes precedence when both are configured.
Set a default routing target when you create the alert source. Rootly bakes it into the webhook URL:
Every alert from this Chronosphere notifier routes to that target — no payload-level routing needed.Best when: a single Chronosphere notifier corresponds to one Rootly team or service.

​
Handling Resolved Events

Resolved events from Chronosphere are silently dropped — they do not close the matching Rootly alert. This is intentional: Chronosphere’s resolved notifications are noisy in environments with high monitor churn, and Rootly treats alert lifecycle as a workflow concern rather than a webhook concern.
What this means in practice:
  • A Chronosphere webhook with "status": "firing" creates or updates a Rootly alert
  • A follow-up webhook with "status": "resolved" is ingested but produces no alert mutation — Rootly returns 200 and discards the event
  • Alerts created from Chronosphere stay in their triggered state until a responder resolves them in Rootly, or until an alert workflow closes them based on its own logic
If you want resolution behavior driven by Chronosphere, build an alert workflow that closes alerts based on time-since-creation, on a downstream signal, or on a manual responder action. Don’t rely on Chronosphere’s resolved notifications to clean up the Rootly side. You can leave Chronosphere’s Notify when resolved toggle off to avoid sending noise that gets discarded anyway.

​
Multi-Alert Payloads

Chronosphere’s Alertmanager-style webhook can include multiple alerts in a single POST under the alerts array — typical when a notification policy groups related monitors together. Rootly collapses the entire batch into a single Rootly alert:
  • The External Identifier is computed as uuid_v5(DNS namespace, fingerprints.sort.join(",")) — every fingerprint in the batch contributes, so the same batch produces the same identifier on retry, and a different batch produces a different identifier
  • The summary comes from commonLabels.alertname (a single field on the batch, not per-alert)
  • The started_at timestamp comes from the first alert in the array (alerts[0].startsAt)
  • The entire payload is preserved on the alert record, so per-alert details remain accessible to alert workflows and field mappings
If you want each Chronosphere alert to be its own Rootly alert, configure Chronosphere’s notification policy to send one alert per webhook (no grouping). Rootly’s parsing matches whatever shape Chronosphere sends.

​
Troubleshooting

The secret query parameter is missing from the webhook URL or doesn’t match the value Rootly generated for this source. Re-copy the full webhook URL from the alert source configuration in Rootly (it includes ?secret=...) and paste it into the Chronosphere notifier’s URL field, replacing the existing one.
A few common causes:
  • The webhook payload had "status": "resolved" — Rootly drops resolved events on purpose (see Handling Resolved Events)
  • Rootly processes webhooks asynchronously; check again after a few seconds
  • Confirm the routing target referenced in the URL or payload exists and isn’t archived
  • Inspect the source’s recent activity in Rootly to verify the payload was received
Each unique fingerprint set produces a separate Rootly alert. If Chronosphere is grouping alerts differently between webhooks (different fingerprints in the batch), Rootly sees them as new alerts. Check the notification policy’s grouping rules in Chronosphere to ensure consistent batching.
URL-based routing takes precedence over payload-based routing. If the webhook URL ends with /notify/<type>/<id>, that target wins regardless of the JSON body. Either remove the URL target and rely on payload routing, or update the URL target to the correct destination.
Open the Chronosphere notifier’s delivery history. Rootly returns 401 if the secret query parameter is missing or wrong, and 500 for server-side issues. For 500 responses, contact Rootly support with the timestamps so they can correlate against server logs.

​
Frequently Asked Questions

No. Rootly ships a dedicated Chronosphere alert source with Alertmanager-style payload parsing, fingerprint-based deduplication, and pre-mapped fields. Use it instead of the Generic Webhook source — you’ll get cleaner setup and built-in batch handling.
Chronosphere’s resolved notifications fire frequently in environments with monitor churn, which would create unwanted lifecycle churn on the Rootly side. Rootly treats alert resolution as a workflow concern — drive it from alert workflows, responder action, or downstream signals rather than vendor recovery webhooks. See Handling Resolved Events for the rationale.
Yes — configure Chronosphere’s notification policy to send a separate webhook per alert (no grouping). Rootly parses each POST independently, so single-alert batches produce single Rootly alerts.
No. Rootly’s Chronosphere source authenticates via the secret query parameter only. Chronosphere’s optional Chronosphere-Webhook-Timestamp + HMAC-SHA256 signature isn’t required or validated. You can leave signing off in Chronosphere without affecting the integration.
Set the source’s default routing target (or the payload’s rootly.notification_target) to an Escalation Policy. Rootly triggers the escalation as soon as the alert is created, paging the on-call responder per the policy’s steps.

​
Next Steps

Alert Routing

Configure routes that send Chronosphere alerts to the right responders based on severity, region, or any custom field.

Alert Workflows

Auto-create incidents, post Slack notifications, run runbooks, and chain follow-up actions from Chronosphere alerts.

Alert Fields

Extract custom fields from Chronosphere’s Alertmanager labels (severity, region, service) for richer routing and reporting.

Schedule Permissions

Confirm which Rootly roles can create and edit this alert source.