Nightingale is an open-source monitoring and alerting system that connects to stored metrics and log data, evaluates alert rules, and distributes notifications. Operations teams use it to manage alarms and explore observability data alongside existing data sources and collectors. Catalogue add-ons provide skills for operating Nightingale.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ccfos/nightingale --skill host-health-diagnosegit clone --depth 1 https://github.com/ccfos/nightingaleWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ccfos/nightingale/host-health-diagnose)<a href="https://agentmods.dev/skills/ccfos/nightingale/host-health-diagnose"><img src="https://agentmods.dev/badge/skills/ccfos/nightingale/host-health-diagnose/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ccfos/nightingale/host-health-diagnose"><img src="https://agentmods.dev/badge/skills/ccfos/nightingale/host-health-diagnose.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00114 | $0.02394 |
| Opus 5 | $0.00057 | $0.01197 |
| Sonnet 5 | $0.00023 | $0.00479 |
| Haiku 4.5 | $0.00011 | $0.00239 |
Grade A, and why
host-health-diagnose scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Host Health Comprehensive Assessment (host-health-diagnose)
Scope
Enter this skill:
- "Why is the machine xxx unreachable / offline / heartbeat stopped"
- "Is the host-unreachable alert a false positive"
- "Is the agent stuck / hung"
- "Is this host really down"
- "This machine is pingable but Nightingale shows it as down"
Do NOT enter this skill:
- Change alert rule thresholds, add/adjust host-unreachable alerts →
creation/troubleshooting - Just "take a look at the machine list / details" →
resource_query - "Why did this alert fire" (not host-unreachable type) →
troubleshooting
One-Sentence Principle
A diagnosis that concludes from a single layer of evidence is almost always wrong.
When n9e shows a machine as unreachable, it may stem from:
- The agent really died (process panic / OOM)
- The agent is still alive but cannot send heartbeats (network partition / DNS / broken proxy / cannot write to Redis)
- Redis write latency on the server side
- The user manually stopped the agent for maintenance but did not add a mute
- The host is really down
The "recommended action" for these five conclusions is completely different. So gather evidence first, then classify, and give the action last.
Three-Layer Evidence Collection (in order, call in parallel)
Layer 1: Real-time heartbeat and metadata — get_target_realtime_status(ident)
Reads Redis to get:
beat_time/lag_seconds— seconds since the most recent heartbeatstatus—active(<60s) /lagging(60–180s) /stale(≥180s) /stale_no_heartbeat(no such key in Redis)offset— clock skew between agent and server (an abnormally large value usually means the agent clock has drifted / NTP is broken)cpu_util/mem_util— resource usage from the most recent reportagent_version/remote_addr/extend_info
Key judgments:
status=stale_no_heartbeatwhileupdate_at_dbis several days ago — the agent has never connected, a deployment problem.status=stale_no_heartbeatwhileupdate_at_dbis a few minutes ago — the Redis layer is down or has been cleared.status=stalewhile the last reportedcpu_util/mem_utilwas low — possibly a graceful exit (shutdown / kernel reclaim after OOM), leaning toward "truly down".status=stalewhile the last reportedcpu_utilwas high (>90%) — leaning toward "agent hung / host hang".- absolute value of
offset> 30s — not necessarily down, but the agent clock has a problem and will throw off alert evaluation, so flag it separately.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 139 lines · 114 tokens per session scan A dfdb9ecfc988
host-health-diagnose is a skill published in the GitHub repository ccfos/nightingale (13,284 stars, last pushed 2d ago), licensed Apache-2.0. It adds 114 tokens to every session and 2,394 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
cis-aws-database-10.8
Ensure Monitoring and Alerting is Enabled.
datadog
Full-stack observability with Datadog APM, logs, metrics, synthetics, and RUM. Use when implementing monitoring, tracing, alerting, or cost optimization for production systems.
Verification & Quality Assurance
Comprehensive truth scoring, code quality verification, and automatic rollback system with 0.95 accuracy threshold for ensuring high-quality agent outputs and codebase reliability.
langsmith-observability
LLM observability platform for tracing, evaluation, and monitoring. Use when debugging LLM applications, evaluating model outputs against datasets, monitoring production systems, or building systematic testing pipelines for AI applications.
phoenix-observability
Open-source AI observability platform for LLM tracing, evaluation, and monitoring. Use when debugging LLM applications with detailed traces, running evaluations on datasets, or monitoring production AI systems with real-time insights.
log-error-digest
Analyze log files to troubleshoot errors, identify peak error periods, and produce error clustering, frequency statistics, and time distribution reports. Supports JSON, syslog, and Nginx formats with automatic detection. Use when a user uploads a .log file and asks to analyze errors, find patterns, debug issues, or…