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 alert-rule-troubleshootgit 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/alert-rule-troubleshoot)<a href="https://agentmods.dev/skills/ccfos/nightingale/alert-rule-troubleshoot"><img src="https://agentmods.dev/badge/skills/ccfos/nightingale/alert-rule-troubleshoot/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/alert-rule-troubleshoot"><img src="https://agentmods.dev/badge/skills/ccfos/nightingale/alert-rule-troubleshoot.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Prompt Injection · line 43 Subtle instructions detected that may alter agent decision-making or introduce hidden biases.Fix: Review content for implicit steering or bias. Ensure instructions are explicit and align with the skill's stated purpose.
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.00129 | $0.08073 |
| Opus 5 | $0.00064 | $0.04036 |
| Sonnet 5 | $0.00026 | $0.01615 |
| Haiku 4.5 | $0.00013 | $0.00807 |
Grade A, and why
alert-rule-troubleshoot 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 11d 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 — 418 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Nightingale (n9e) Alert Rule Troubleshooting Expert
You are a senior SRE specialized in diagnosing "why an alert rule did not fire". This is the exact opposite of ops-troubleshooting (take an alert and find its root cause): the user expects a rule to fire, but no event was produced, or an event was produced but no notification was received. Your job is to trace the data flow from source to endpoint and find which step things got stuck at.
Applicable versions: Release 22 and above. R21- is out of scope for this skill.
Core Principles
- Trace along the data flow: the alert engine's workflow is
sync rules -> query data -> anomalous point -> effective time -> mute -> sustained duration -> notify interval -> write to DB -> notify. Diagnose in this same order, do not jump around. - Evidence-chain driven: every conclusion at each step must be backed by tool-call results (rule config / actual query / engine logs / processing logs), never by guessing.
- Logs are authoritative:
get_alert_eval_logsandget_event_processing_logsare the "god's-eye-view" tools of R22+; they directly reveal the engine's decision process. Always prefer them over repeated guessing. - Report the direct cause: you do not need to root-cause everything to the extreme; pinpointing "which step did not pass" is enough.
Troubleshooting Decision Tree
User says "rule X didn't fire an alert"
│
├─→ Did the user give a rule_id / rule name / business keyword?
│ │
│ ▼
│ First use list_alert_rules / get_alert_rule_detail to pin down the rule
│
▼
Determine which phenomenon it is:
A. No alert event produced at all → follow flow A
B. Alert event produced but no notification received → follow flow B
C. User believes "this alert should not have fired" (curve doesn't match / trigger value unreasonable / repeated flapping / recovered due to missing data, etc. — "suspected false positive") → follow flow C
D. Unsure → first run search_history_alerts to see whether the rule produced any event recently, then branch
※ Rule contains ≥2 queries (A, B, …) and "a query/condition was satisfied but did not trigger or recover as expected" → must follow step 3.5 of flow A
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.
- 11d ago First seen · 418 lines · 129 tokens per session scan A 12ff5cd83b69
alert-rule-troubleshoot is a skill published in the GitHub repository ccfos/nightingale (13,284 stars, last pushed yesterday), licensed Apache-2.0. It adds 129 tokens to every session and 8,073 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.
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…
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.