# nightingale [Health: Active]

**Category:** 📊 Monitoring  
**Repository:** https://github.com/ccfos/nightingale  
**GitHub Stars:** 13399  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/nightingale

## Description
Open-source, self-hosted alerting for metrics, logs, and databases. Includes a built-in AI agent and MCP server.

## Claude Desktop Quick Installation
No confirmed install details yet, so no config is published. Follow the setup steps in the repository above.

## Documentation

## What nightingale does

Nightingale provides alerting for metrics, logs, and database queries, and its MCP interface lets external assistants work with that monitoring system. Agents can retrieve monitoring data and configuration to investigate alerts, examine affected hosts, review alert evaluation history, and trace notification delivery.

The interface also supports configuration workflows when write tools are enabled. These workflows can include creating or changing alert rules and dashboards, configuring notification rules, mutes, and subscriptions, and generating PromQL or SQL for monitoring tasks.

Nightingale remains the system of record for the monitored data and alert configuration. It can query Prometheus-compatible sources, VictoriaMetrics, Elasticsearch, Loki, ClickHouse, PostgreSQL, and other configured sources while leaving data in its existing stores.

## How it works

The MCP server runs inside Nightingale and is available at `/mcp`. External assistants connect to that endpoint and invoke Nightingale’s tools. Read tools are exposed by default, so an agent can investigate monitoring state without automatically changing configuration.

MCP requests are evaluated using the caller’s existing Nightingale API permissions. Write tools require explicit configuration before an agent can use them. This gives administrators separate control over whether assistants may only inspect data or also propose and apply configuration changes.

The same monitoring system handles alert evaluation, event processing, and notification routing. Nightingale can send notifications through channels such as Slack, PagerDuty, Discord, email, Telegram, Mattermost, Jira, and Jira Service Management, with webhooks and scripts available for custom destinations.

## Setup and configuration

Run Nightingale using one of its supported deployment approaches, such as the included Docker Compose evaluation stack, Linux binaries, or the Kubernetes Helm chart. The MCP endpoint is part of the Nightingale application rather than a separate standalone process.

Configure the external assistant to connect to Nightingale’s `/mcp` endpoint. Authentication and authorization follow Nightingale’s API access model, so the connecting identity must have permission to perform the requested operations. Enable write tools only after reviewing the access policy appropriate for the deployment.

For local evaluation, the Compose setup starts Nightingale alongside MySQL, Redis, VictoriaMetrics, and Categraf. The example stack uses sample credentials and exposed service ports; change credentials and review network access before using it on a shared or public host.

## Tools and capabilities

- Inspect related metrics and logs during alert investigations.
- Examine affected hosts and monitoring data around a trigger time.
- Review alert rules, evaluation records, active and historical events, and notification results.
- Diagnose mute settings, event processing, and delivery problems.
- Create or update alerting and dashboard configuration when write access is enabled.
- Configure notification rules, mutes, and subscriptions through supported tools.
- Generate PromQL and SQL for monitoring workflows.
- Extend agent workflows with Skills containing procedures, reference material, or scripts.

## Limitations and notes

The MCP server’s behavior depends on the Nightingale permissions assigned to the connecting caller. Read access is the default, and write access must be deliberately enabled. Core alerting does not depend on Nightingale’s built-in AI agent; the AI agent and external MCP assistants are separate ways to operate the monitoring system.

Production deployments should use controlled credentials and TLS, back up the metadata database, and monitor rule-evaluation and notification failures. Multiple Nightingale instances share metadata storage and Redis, while the embedded time-series database is local to one instance and is intended for small, single-instance deployments.

_Full upstream README: https://allmcps.com/mcp/nightingale/readme_