Nezha Monitoring V2 Docs

English

简体中文

English

简体中文

Appearance

Nezha Monitoring V2From server monitoring to AI-assisted operations

One Dashboard for your servers. Monitor state and alerts, then use MCP to bring AI agents into inspections, diagnosis, and authorized operations.

Preview
Install Dashboard →
Explore MCP & AI Operations →

Multi-server monitoring

View online state, CPU, memory, disk, network traffic, and available system metrics from Linux, Windows, macOS, OpenWRT, Synology, and other documented environments.

Service checks and alerts

Run HTTP GET, ICMP Ping, and TCPing from selected Agents, track availability, latency, and certificate state, and send alerts through notification groups.

Routine remote operations

Use web terminal, file management, scheduled and triggered tasks, DDNS, NAT, REST API, and optional MCP according to granted permissions.

Connect AI agents through MCP

Use Codex, OpenClaw, and Claude Code to inspect servers, read logs, investigate issues, and carry out operations you authorize.

Explore AI operations

Automation you can verify

Have AI check current state, make authorized changes, and verify the service afterward. Get findings and results, not just suggestions.

Explore practical scenarios

Self-hosted and open source

Dashboard and Agent are published by NezhaHQ; the operator controls data, endpoints, users, storage, and integrations.

What is Nezha Monitoring V2? ​

Nezha Monitoring V2 combines a central Dashboard with an Agent installed on every monitored device. Agents report host state and perform assigned network checks or authorized tasks. Dashboard manages identity and access, visualization, service monitoring, alert notifications, APIs, and configuration.

Typical use cases ​

ScenarioNezha V2 entry point
Multi-region VPS and cloud serversCentral online state, resources, traffic, groups, alerts, and authorized remote operations
Website and port availabilityHTTP, Ping, TCP, latency, packet loss, HTTPS certificate state, and failure notifications
Home labs, NAS devices, and small teamsSelf-hosted Dashboard, users, public or authenticated status views, tasks, and file operations
AI operations and agentsUse MCP with Codex, OpenClaw, or Claude Code for inspections, diagnosis, and verified changes; combine REST API access for management configuration

If your primary goal is a public status page, second-by-second deep observability, the PromQL ecosystem, or enterprise network-device management, read the comparison with Uptime Kuma, Netdata, Prometheus/Grafana, and Zabbix.

Start in five steps ​

  1. Read Architecture and data flow and prepare domains, ports, TLS, and backup storage.
  2. Install Dashboard and replace the default password immediately.
  3. Install Agent, then confirm the first server stays online and reports continuously.
  4. Configure service monitoring and notifications.
  5. Complete the security and privacy checklist before adding more users, APIs, or remote operations.

Official resources ​

Frequently asked questions ​

Which operating systems can Nezha Monitoring V2 monitor? ​

Official installation and documentation cover Linux, Windows, and macOS, with additional guidance for OpenWRT, Synology, and other environments. Available metrics depend on the operating system, permissions, hardware, and Agent configuration.

Must Dashboard and Agent use the same version? ​

They are released independently and do not require identical version numbers. Read both release notes and validate on a small set of nodes before a broad upgrade. See Version and compatibility.

Can Nezha V2 monitor websites and SSL certificates? ​

Yes. HTTP GET service monitoring checks URL availability, and HTTPS targets are also checked for certificate state. Ping and TCPing cover network reachability and ports.

Must data be uploaded to a third-party cloud? ​

No. Dashboard and Agent can be self-hosted. Integrations such as OAuth2, notifications, DDNS, a CDN, or an AI client may send relevant data to external services. When using an external model, check how the client handles tool results, logs, and file contents.

Why do current API routes still use /api/v1? ​

API route version and product generation are separate. The current product is V2 while the implemented REST API continues to use /api/v1. Do not change routes to /api/v2 unless official code introduces them.