> ## Documentation Index
> Fetch the complete documentation index at: https://docs.squasher.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Grafana OnCall to Squasher

> Plan a Grafana OnCall OSS migration and responder onboarding flow with Squasher incident context.

Grafana OnCall OSS is archived as of March 24, 2026. Treat migration as a coverage and responder-readiness project, not only an integration swap.

Use Squasher for telemetry, AI triage, monitor-driven incidents, incident evidence, on-call rotations, escalation policy context, and status workflows. Keep a dedicated paging system only for delivery modes you still require outside Squasher.

## Source checkpoints

* [Grafana OnCall maintenance notice](https://grafana.com/blog/grafana-oncall-maintenance-mode/)
* [Grafana OnCall OSS setup notice](https://grafana.com/docs/oncall/latest/set-up/)
* [Grafana Cloud IRM migration guide](https://grafana.com/docs/grafana-cloud/alerting-and-irm/irm/set-up/migrate/oncall-oss/)

## Inventory

Document the current operating model before changing alert routes:

* Users, teams, service owners, and backup responders
* Rotations, overrides, holidays, calendars, and time zones
* Escalation chains, route rules, grouping behavior, and severity mapping
* Integrations, ChatOps hooks, runbooks, notification preferences, and audit needs
* Alert sources that must be parallel-run during the cutover window

## Migration pattern

<Steps>
  <Step title="Pick one service">
    Start with one service that has clear ownership and enough alert traffic to validate the
    workflow.
  </Step>

  <Step title="Rebuild responder coverage">
    Recreate the Grafana OnCall rotation in Squasher, then verify the schedule, current engineer,
    calendar feed, runbook link, and severity routing.
  </Step>

  <Step title="Mirror alerts">
    Send copied alerts to the new path while Grafana OnCall OSS remains visible. Compare
    acknowledgements, escalations, and duplicate noise.
  </Step>

  <Step title="Connect Squasher context">
    Add Squasher monitors, log or error ingestion, status workflows, and incident links so
    responders have evidence after alerts arrive.
  </Step>

  <Step title="Cut over deliberately">
    Move the service route, name the rollback owner for the first week, then retire duplicate
    notifications after one deploy cycle.
  </Step>
</Steps>

## Onboarding checklist

* Confirm every responder can sign in to the new incident workflow.
* Verify time zones, contact methods, notification preferences, and quiet hours.
* Test SMS, push, email, Slack, and phone delivery in the tool responsible for paging.
* Run one shadow week with both old and new routes visible.
* Review missed, duplicate, and delayed notifications before switching the next service.
* Train responders on Squasher incident pages, monitor history, AI triage, and status update workflows.

## Squasher setup

* Use [status monitoring](/features/status-monitoring) for monitor-driven incidents and status-page updates.
* Use [on-call](/features/on-call) to recreate and verify Grafana OnCall schedules before cutover.
* Use the [Query Guide API](/api-reference/query-guide) for script and agent discovery of logs, traces, monitors, and incidents.
* Use [OpenTelemetry](/integrations/opentelemetry), [log drains](/integrations/logging-overview), or SDKs to preserve investigation context.
* Use [status pages](/features/status-pages) when customers need public updates during incidents.

## Cutover validation

* A test alert reaches the right responder and escalation path.
* The responder can find the linked Squasher incident, evidence, logs, traces, monitor checks, and runbook.
* Status updates are published only by the owners you expect.
* Rollback ownership is documented for the first week after cutover.
* Duplicate Grafana OnCall routes are removed only after the overlap window is complete.

## Agent handoff

```text theme={null}
Plan a Grafana OnCall OSS migration with Squasher context for project <project_id>. Inventory responders, routes, alert sources, and runbooks first. Use Squasher Query Guide, status monitoring, and on-call schedule/calendar checks for context, and ask before creating schedules or changing paging routes/status update permissions.
```