> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Chronosphere > Connect Chronosphere to Rootly to turn observability alerts into actionable incidents, paging on-call responders directly from monitor notifications. ## 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. Fire escalation policies the moment a Chronosphere monitor triggers, paging the right responder in seconds. Turn a monitor alert into a full Rootly incident with custom fields, workflows, and Slack channels. Chronosphere's Alertmanager-style batches collapse into a single Rootly alert, keyed on the sorted fingerprint set. 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](/on-call/schedules#permissions-access). * **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. In the Rootly dashboard, navigate to **Alerts → Sources** and click **New alert source**. Select **Chronosphere** from the list of available sources and give the source a descriptive name — for example, `Chronosphere — Production Monitors`. 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](#routing-alerts). 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: ```text theme={null} https://webhooks.rootly.com/webhooks/incoming/chronosphere_webhooks?secret= ``` With a default routing target baked into the URL: ```text theme={null} https://webhooks.rootly.com/webhooks/incoming/chronosphere_webhooks/notify//?secret= ``` *** ## Configure the Webhook in Chronosphere Create a webhook notifier in Chronosphere, point it at the Rootly URL, then attach it to a notification policy. 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](https://docs.chronosphere.io/investigate/alerts/notifications/notifiers/webhook). 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. 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](#handling-resolved-events) below). 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. The monitor's alert name from Chronosphere's common labels. Populates the Rootly alert's summary. Defaults to `"Alert from Chronosphere"` if absent. Array of one or more alert objects. Each contains at minimum a `fingerprint` and a `startsAt` timestamp. 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. When the first alert in the batch began firing. Populates the Rootly alert's started-at timestamp. Direct link back to the Chronosphere alert view. Preserved on the alert record for responders to jump straight to the source. Either `firing` or `resolved`. See [Handling Resolved Events](#handling-resolved-events) for behavior differences. 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: ```text theme={null} https://webhooks.rootly.com/webhooks/incoming/chronosphere_webhooks/notify/Service/?secret= ``` 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. Leave the default target empty on the Rootly source. In Chronosphere's notifier payload template (or your notification policy variables), inject a `rootly` object naming the target. Most teams use a separate Chronosphere notifier per Rootly target rather than templating per alert, but both work. ```json theme={null} { "rootly": { "notification_target": { "type": "Service", "id": "8c4a5e91-1b2d-4c3e-9f6a-7d8b2c5e9a01" } } } ``` Valid `type` values are the Rootly resource class names: `Service`, `Group`, or `EscalationPolicy`. The `id` is the Rootly resource's internal ID — open the resource in Rootly and copy it from the edit page. Names and slugs aren't accepted. **Best when**: different notifiers (or different notification policies) need to page different teams. *** ## 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](#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//`, 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](#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 Configure routes that send Chronosphere alerts to the right responders based on severity, region, or any custom field. Auto-create incidents, post Slack notifications, run runbooks, and chain follow-up actions from Chronosphere alerts. Extract custom fields from Chronosphere's Alertmanager labels (severity, region, service) for richer routing and reporting. Confirm which Rootly roles can create and edit this alert source.