Nightingale

Nightingale is an open-source alerting platform purpose-built for teams that already have monitoring data but need a powerful, independent alerting layer on top of it. Rather than replacing your Prometheus, VictoriaMetrics, or Elasticsearch setup, Nightingale connects to these as data sources and takes ownership of rule evaluation, noise reduction, and multi-channel notification delivery. It was originally developed at DiDi and donated to the China Computer Federation Open Source Development Committee in 2022.

The platform handles the full alerting lifecycle: rules fire from PromQL, Elasticsearch queries, SQL statements, or log patterns; events flow through configurable pipelines that can relabel, enrich, drop, or trigger AI-generated summaries; and notifications are dispatched to channels ranging from email and SMS to DingTalk, Slack, Feishu, and custom webhooks. A business group permission model lets large organizations carve up alerting ownership by team or service area.

For teams operating in environments where connectivity between remote sites and a central data center is unreliable, Nightingale offers an edge deployment mode. The n9e-edge binary runs locally in a disconnected data center, evaluates alerting rules against local data sources, and continues firing alerts even when the central Nightingale server is unreachable. This makes it practical for logistics, manufacturing, and multi-region deployments where network partitions are routine.

Starting with v9, Nightingale integrates an AI agent layer built on the Model Context Protocol. The agent can manage alerts, query monitoring data, and execute observability tasks through natural language — making it one of the first open-source alerting platforms to ship an MCP server as a first-class feature.

What You Get

• Multi-datasource Alert Rules - Write alerting rules against Prometheus, VictoriaMetrics, ClickHouse, Elasticsearch, Loki, MySQL, PostgreSQL, TDengine, VictoriaLogs, and OpenSearch — all managed in a single rule engine without separate tooling per datasource.
• Configurable Event Pipelines - Route alerts through ordered pipeline processors that can relabel fields, enrich events with metadata, drop unwanted noise, evaluate conditional logic, trigger HTTP callbacks, or attach AI-generated summaries before any notification is sent.
• Edge Alerting for Disconnected Sites - Deploy n9e-edge in remote data centers that have poor or intermittent connectivity to the central server; alerting evaluation runs locally and continues firing without a live connection back to headquarters.
• 20+ Built-in Notification Channels - Native senders for email, SMS, phone calls, DingTalk, Slack, Feishu, Lark, WeChat, Telegram, and webhooks, with per-channel message templates and customizable routing rules per alert severity.
• Business Group Permission Model - Organize alert rules, dashboards, subscriptions, and target machines into business groups with role-based access control, so each team only sees and manages their own alerting scope in a shared platform.
• AI Agent with MCP Server - A built-in agent layer speaks the Model Context Protocol, letting AI assistants interact with Nightingale’s API in natural language to query alerts, check monitoring data, silence alarms, and perform observability tasks.
• Alert Self-Healing Automation - Configure Nightingale to automatically execute a script or ibex command when an alert fires — clearing disk space, capturing system state, restarting a service — before or instead of paging a human.
• Built-in Integration Catalog - Pre-packaged dashboards and alerting rule sets for Linux, MySQL, Redis, Oracle, Kubernetes, and other common middleware, contributed by the community and importable with a single click.

Common Use Cases

• Consolidating alerts from a hybrid stack - A platform team connects on-prem VictoriaMetrics, AWS CloudWatch metrics via Remote Write, and Elasticsearch logs into Nightingale’s rule engine, replacing a patchwork of per-system alerting configs with a single interface for all alert rules and routing.
• Suppressing alert fatigue during deployments - An SRE team creates time-windowed mute rules that silence non-critical alerts during scheduled maintenance windows, and configures event pipelines to drop transient recovery storms after rolling restarts.
• Alerting in edge manufacturing plants - A factory operator deploys n9e-edge on local servers in each plant; when the WAN link to corporate drops, the edge binary continues evaluating rules against local Prometheus and triggers SMS alerts via a local gateway.
• Team-scoped alerting for multi-tenant infrastructure - A cloud provider hosts Nightingale as an internal service, assigning each customer team to a business group so they can create and manage their own alert rules, dashboards, and notification channels without touching other tenants’ config.
• AI-assisted on-call investigation - An on-call engineer connects their AI assistant to Nightingale’s MCP server, then asks in natural language to summarize active alerts, identify correlated events, and acknowledge silences — without opening the web UI.

Under The Hood

Architecture Nightingale is built as a collection of independently compilable Go binaries — n9e (center), n9e-edge, n9e-alert, n9e-pushgw, and n9e-cli — each encapsulating a bounded domain but sharing a common model and context layer. The center binary is the most complete, embedding the full alert engine, push gateway, and HTTP API server into one process for simpler deployments. A shared in-memory caching layer (memsto) decouples hot-path alert evaluation from repeated database queries, with invalidation driven by a cron-based sync loop. Alert pipeline processors are registered via blank imports, making the pipeline extensible without modifying core routing logic. Frontend assets are downloaded and embedded into the binary at build time via a shell script and statik, producing a single self-contained binary that requires no web server.

Tech Stack The backend is written in Go 1.25, using Gin as the HTTP framework and GORM for database access against MySQL, PostgreSQL, or SQLite. Redis is used for pub/sub coordination between the center and edge nodes and for distributed caching. Kafka integration via IBM Sarama enables high-throughput event streaming. Datasource adapters are maintained for Prometheus, VictoriaMetrics, ClickHouse, Elasticsearch/OpenSearch, Loki, VictoriaLogs, MySQL, PostgreSQL, TDengine, and Doris — each implementing a common datasource interface. SSO is handled through pluggable modules for LDAP, OIDC, OAuth2, CAS, and DingTalk. The AI agent layer uses a structured LLM client abstraction with a client cache, and speaks the A2A (agent-to-agent) and MCP protocols for interoperability with external AI tooling. Builds use goreleaser for multi-architecture release artifacts and Docker images.

Code Quality The codebase demonstrates solid Go discipline with comprehensive test coverage across core model logic — alert rule parsing, mute condition evaluation, subscription matching, AI skill registration, and pub/sub bus behavior all have dedicated test files. Error handling is explicit and typed throughout the models layer, with validation methods that return descriptive errors before any database write. The alert rule model carries deprecated fields alongside their successors with clear comments, prioritizing backwards compatibility over pruning. Inline comments are present but concentrated in complex logic rather than routine boilerplate, reflecting a practical rather than exhaustive documentation style. CI configuration is present with automated checks.

What Makes It Unique Nightingale’s most distinctive capability is its first-class AI integration: the aisummary pipeline processor can attach LLM-generated incident summaries to alert events before they are routed, and the embedded MCP server exposes Nightingale’s entire alert management surface to any MCP-compatible AI assistant. The A2A protocol support allows Nightingale to participate in multi-agent observability workflows, a capability absent from comparable open-source alerting tools. The edge deployment architecture addresses a concrete gap in the alerting ecosystem — most platforms assume reliable connectivity, while n9e-edge is explicitly designed for environments where that assumption fails. The combination of a Prometheus-compatible rule engine, multi-datasource SQL and log alerting, and AI-driven triage in a single deployable binary covers a surface area that typically requires three or four separate tools.

Self-Hosting

Nightingale is released under the Apache License 2.0, one of the most permissive open-source licenses available. You can use it commercially, modify the source code, distribute your changes, and incorporate it into proprietary products without any copyleft obligations — as long as you preserve copyright notices and the license text. There are no contributor license agreements, no open-core restrictions, and no community-edition feature caps enforced in the codebase.

Running Nightingale yourself requires a relational database (MySQL or PostgreSQL for production; SQLite works for single-node testing), Redis for pub/sub and caching, and your existing time-series or log storage as configured datasources. The center binary is self-contained and serves the embedded frontend, so there is no separate web server to manage. Operationally, you are responsible for database backups, Redis availability, and keeping the binary up to date — Nightingale releases frequently (roughly every three to four weeks), so patch cadence requires active maintenance attention. High availability for the alerting engine requires running n9e-edge or configuring multiple alert shards, which adds operational complexity.

There is no official paid cloud or SaaS version of Nightingale itself, but the project is commercially backed by Flashcat, which offers FlashDuty — a managed on-call and alert routing product. FlashDuty adds features Nightingale explicitly does not target: personnel scheduling, on-call rotation, alert escalation chains, SLA tracking, and collaborative incident handling. If you need those capabilities, Flashcat positions FlashDuty (with a free tier) as the natural complement. For self-hosters who want only the core alerting engine, Nightingale is fully functional without any commercial dependency.