Your metrics live in Prometheus. Logs sit in Loki. Someone glued Alertmanager rules together three years ago in a repo nobody owns. PagerDuty gets the page, but nobody can answer why the rule fired, who changed the threshold, or whether the notification actually left the building. Grafana stays for charts; the alert story is still scattered.
Nightingale (~13.4k stars, Apache-2.0) is self-hosted alerting for the stack you already run: evaluate rules against Prometheus, VictoriaMetrics, Elasticsearch, Loki, ClickHouse, PostgreSQL, and more, then route events to Slack, PagerDuty, Discord, email, Telegram, Jira, or webhooks. Business groups and team permissions live in one UI. Optional built-in AI agent and MCP server sit on top — alerting does not depend on them.
What it adds over "just Alertmanager"
Nightingale is not trying to replace your TSDB or Grafana dashboards. It queries data where it already lives, runs PromQL, log queries, or SQL conditions, and handles event pipelines: mutes, subscriptions, label rewrites, conditional routing. You get evaluation records, historical events, and delivery logs so "did Slack get it?" is a click, not a log grep across three hosts.
Teams map rules to business groups, use OIDC/OAuth2/LDAP/CAS for sign-in, and import Prometheus rule YAML (expressions, durations, labels) — then rebuild notification routing in Nightingale before you cut over. Rules export as JSON and update via HTTP API for Git-driven workflows.
Need collectors? Categraf plugs in for hosts, middleware, and databases. Small shops can use an embedded TSDB on a single instance; production setups pin releases, use external time-series storage, and scale engines with shared MySQL metadata and Redis.
AI and MCP (optional)
The in-app agent can investigate an alert (pull related metrics and logs), trace why something did not notify, or draft rules and dashboards from plain language — with confirmation before it changes production config. Point it at an OpenAI-compatible endpoint, Claude, Gemini, or a model on your LAN; credentials stay yours.
External assistants can call Nightingale through MCP at /mcp (read tools by default; write tools need explicit enablement). A2A lets another agent delegate tasks to Nightingale's agent. None of this is required for core paging.
Why self-host?
Alert metadata is operational gold. Who muted what, which rule version fired, which channel failed — that belongs on infrastructure you control, especially if you're a Canadian org with data-residency expectations on internal monitoring.
SaaS APM alert modules add up. Nightingale is Apache-licensed; you pay for compute and the on-call tool you already use, not per-seat alert management.
Unified layer without migration day. Keep VictoriaMetrics or Prometheus endpoints, keep Grafana, connect PagerDuty for schedules and escalation. Nightingale becomes the alert brain, not a rip-and-replace monitoring project.
Getting it running
Fast path: clone the repo and bring up docker/compose-bridge — Nightingale, MySQL, Redis, VictoriaMetrics, and Categraf. UI on port 17000 (default login documented in their README is for evaluation only; change passwords before anything public). Production image: flashcatcloud/nightingale on Docker Hub.
Plan for MySQL (metadata), Redis (cluster coordination), TLS on the UI, backups of the config database, and enough CPU for rule evaluation if you fan out many PromQL queries. Multi-instance deployments share metadata DB and Redis; do not rely on embedded TSDB disk on one node for HA.
Pair with a Canadian VPS or Docker host close to your workloads so alert evaluation latency stays honest.
Who should look at it
Good fit: platform teams drowning in YAML sprawl, MSPs managing customer stacks, anyone on Prometheus-compatible metrics who wants one place for rules, muting, and notification audit trails.
Skip it if you only need external uptime checks — a lighter tool might suffice. Nightingale shines when metrics, logs, and SQL-backed checks share one routing and ownership model.
We host the Linux side, firewall rules, and backups. Tell us your data sources and notification channels and we'll size MySQL, Redis, and HA before you import your first Prometheus rule pack.
