ccfos/nightingale

What it does

Nightingale is an alerting and event-routing layer that sits on top of monitoring data you already run. It queries Prometheus, VictoriaMetrics, Elasticsearch, Loki, ClickHouse, and other sources, evaluates PromQL, log queries, or SQL conditions, processes events, and delivers notifications to Slack, PagerDuty, Discord, email, Telegram, Mattermost, Jira, and webhooks. Rules and dashboards are organized by business group with team permissions, and authorization can go through OIDC, OAuth2, LDAP, or CAS.

It is aimed at SRE and platform teams that already have collectors and storage but need centralized rule ownership, inspection of why an alert fired or failed to notify, and distributed evaluation via n9e-edge near remote data sources. The embedded TSDB and Categraf collector are optional for small deployments; existing Grafana dashboards and on-call scheduling stay in their own tools.

An AI agent inside the web UI can investigate alerts, inspect evaluation logs and notification results, and propose rule or dashboard changes for confirmation. External agents can call Nightingale tools through the built-in MCP server at /mcp or delegate work over A2A. Alerting runs independently of the agent.

Quick start

Install Git and Docker Compose, then start the bundled evaluation stack from the repository:

git clone https://github.com/ccfos/nightingale.git
cd nightingale/docker/compose-bridge
docker compose up -d

The stack starts Nightingale, MySQL, Redis, VictoriaMetrics, and Categraf. Open http://localhost:17000 and sign in with root / root.2020.

1. Add a data source: use your Prometheus-compatible endpoint, or http://victoriametrics:8428 for the included VictoriaMetrics instance.
2. Create an alert rule under a business group, enter a PromQL expression such as vector(1) > 0, and set the duration to 0 for an always-firing test.
3. Create a notification channel and rule, attach it to the alert rule, confirm the test notification arrives, then disable the test alert.

The Compose file uses example credentials and exposes service ports for local evaluation; change credentials and review network exposure before running on a shared host. Other deployment paths include Linux binaries from releases, a Helm chart for Kubernetes, and the installation guide.

Usage constraints

Production deployments should pin a release, configure credentials and TLS, back up the metadata database, and monitor evaluation and notification failures. Multiple instances share a MySQL metadata database and Redis and need external time-series storage; the embedded TSDB is single-instance and local-disk only. The Compose stack is for local evaluation.

Prometheus YAML alert rules can be imported, but alertmanager.yml routing is not fully converted, so teams should run both systems during evaluation before switching notifications. Rules can be exported as JSON and changed through the HTTP API for a Git/CI workflow, but there is no built-in rule revision history or rollback.

The AI assistant sends prompts and the retrieved monitoring data to whichever OpenAI-compatible, Claude, Gemini, or self-hosted model endpoint you configure; model credentials and costs are yours. MCP write tools require explicit configuration, and the server applies the caller's existing API permissions. On-call schedules and escalation are not built in and require a separate platform such as PagerDuty. The project is Apache-2.0 licensed.

HotRepo's take

Nightingale appeared at 16th on the GitHub Go daily list on 2026-11-04 with 10 new stars that day, a modest position for a project that has been public since 2020 and now has about 13.4k stars. That fits a mature, self-hosted SRE tool rather than a fast-moving novelty: its value is in consolidating alert rules and notification routing across existing data sources, not in replacing Prometheus or Grafana. A 2023 Hacker News thread framed it as an open-source alternative to Prometheus and Grafana, with one commenter describing it as an all-in-one option; today's README is narrower, positioning Nightingale as the alerting layer while keeping Grafana for visualization and an on-call platform for escalation. That scoping is the more useful way to evaluate it.