Self-hosted PagerDuty MCP alternatives
PagerDuty's MCP server can run locally over stdio as well as through its OAuth-hosted option, so it belongs in this group: the process and your API token stay on infrastructure you control, while the incident data goes to the PagerDuty API. It ships read-only by default across its 64 tools.
The servers below also install locally. Most query the telemetry behind an alert; a few reach into security and deployment, which is where investigation often leads once an incident points at a code or infrastructure change. Each keeps its credentials in a process you operate.
The 8 best self-hosted alternatives
Grafana Labs' server runs locally and queries dashboards, Prometheus, Loki, incidents, alerts, and OnCall, so an agent can investigate telemetry and touch on-call from a process you control.
Set up Grafana →Sentry's server installs locally and pulls issues, stack traces, and events while running Seer root-cause analysis. It gives an agent the error detail behind a page without leaving your own machine.
Set up Sentry →Point the local Prometheus server at your own instance and an agent runs PromQL instant and range queries, discovers metrics, and inspects scrape targets, all from a process you operate.
Set up Prometheus →SigNoz runs self-hosted and OpenTelemetry-native, and its server reaches traces, logs, metrics, dashboards, and alerts. A single local server for the telemetry an investigation needs.
Set up SigNoz →Broader than monitoring, the AWS Labs server runs locally and executes any AWS CLI command with validation and a read-only mode. Reach for it when an incident touches cloud infrastructure beyond your observability tool.
Set up AWS (AWS Labs) →When an incident traces back to a vulnerability, Snyk's server, built into the Snyk CLI, scans dependencies, code, containers, and IaC locally where the code is written. It is a security tool that pairs with incident response, not a paging replacement.
Set up Snyk →SonarQube's server brings code quality, security, and coverage analysis to an agent locally. It fits the post-incident question of what in the code caused the problem rather than who to page.
Set up SonarQube →For GitOps deployments, the Argo CD server runs locally to list and sync applications, read resource trees and workload logs, and run resource actions. Useful when an incident points at a recent deploy.
Set up Argo CD →
How to choose
For self-hosted incident work, the on-call side stays with PagerDuty's own local server; the telemetry side goes to Grafana, Prometheus, or SigNoz, with Sentry for errors. AWS, Snyk, SonarQube, and Argo CD extend an investigation into infrastructure, vulnerabilities, code quality, and deploys. One caveat: running the server locally keeps the process and token on your machine, but the data still travels to each product's API or instance.
FAQ
- Can the PagerDuty MCP server be self-hosted?
- Yes. It runs locally over stdio in addition to its OAuth-hosted option, so the process and your API token stay on infrastructure you control. Incident data still goes to the PagerDuty API, and the server runs read-only by default.
- Are these all incident-response replacements?
- Not all. Grafana, Prometheus, SigNoz, and Sentry are telemetry servers an agent uses to investigate an alert. AWS, Snyk, SonarQube, and Argo CD reach into infrastructure, security, code quality, and deployments, so they extend an investigation rather than handle paging the way PagerDuty does.