Self-Hosted Observability Directory

Migration playbook

Replace Sentry with OSS error tracking

A focused plan for replacing hosted Sentry with self-hosted error tracking while preserving release, source map, alerting, and ownership workflows.

Vendor Sentry
Timeline 4-8 weeks
Difficulty Medium

Error tracking migrations are narrower than full observability migrations, but they touch developer workflows directly. Preserve release and ownership behavior before optimizing for cost.

Recommended OSS Stack

GlitchTip

Sentry-API-compatible error tracking, but MIT-licensed and lighter. Drop-in for Sentry SDKs.

MIT · Python / Django · ★ 1200 · Fresh
replaces sentry errors

Grafana OnCall

Open-source on-call and incident-response — schedules, escalation policies, ChatOps. The closest OSS analog to PagerDuty.

AGPL-3.0 · Python / TypeScript · ★ 3500 · Fresh
replaces pagerduty alerts

Stack Options

Self-host Sentry

Best for: Teams that want maximum SDK and workflow compatibility with hosted Sentry.

Sentry (Self-Hosted) · Grafana OnCall

  • Highest feature compatibility, but the deployment is heavier than most error trackers.
  • Operational upgrades and storage growth become internal responsibilities.

Lean error tracking

Best for: Smaller teams that mainly need issue grouping, alerts, and project-level ownership.

GlitchTip · Grafana OnCall · OpenTelemetry Collector

  • Simpler to operate, but advanced Sentry workflow parity should be checked carefully.
  • Some SDK and release-management features may need process changes.

Migration Phases

  1. Inventory Sentry projects

    1 week

    Outcome: Projects, DSNs, environments, alert rules, ownership rules, and release workflows are mapped.

    • Export project settings, alert rules, team ownership, and inbound filter choices.
    • List SDK versions, source map uploads, release naming conventions, and environments.
    • Identify compliance or retention requirements for event payloads.

  2. Deploy replacement and mirror events

    1-2 weeks

    Outcome: Selected apps can send errors to both Sentry and the replacement system.

    • Provision the self-hosted error tracker with backups, mail, auth, and retention configured.
    • Dual-write low-risk applications or stage traffic through environment-specific DSNs.
    • Verify grouping, breadcrumbs, release tags, and stack traces.

  3. Move ownership workflows

    1-2 weeks

    Outcome: Teams receive actionable alerts and can triage issues without hosted Sentry.

    • Recreate alert rules and route critical issues to on-call or team channels.
    • Validate source map or debug symbol upload in CI.
    • Rebuild project ownership conventions and escalation expectations.

  4. Cut over project by project

    1-3 weeks

    Outcome: Applications use the replacement DSNs and hosted Sentry is kept only for rollback or historical lookup.

    • Switch DSNs one project at a time and monitor event volume, grouping, and alert noise.
    • Freeze new hosted Sentry project creation during the migration.
    • Export or document historical issue references before cancellation.

Cutover Checklist

  • Every production DSN has a target replacement DSN.
  • Source maps or debug symbols upload successfully from CI.
  • Critical issue alerts reach the right team.
  • Retention, attachment, and PII policies are configured.
  • Historical issue lookup expectations are documented.

Risks To Manage

  • Hosted Sentry feature usage can be deeper than teams remember, especially releases and ownership rules.
  • Self-hosted Sentry is operationally substantial and should not be treated as a tiny service.
  • Switching DSNs without dual-write validation can hide grouping or source map regressions.

Back to migration playbooks