alert-investigation
starsforks
How to install alert-investigation?
launchdarkly/ai-tooling/alert-investigation
$npx -y skills add launchdarkly/ai-tooling --skill alert-investigationInvestigates a triggered observability alert and returns a structured diagnosis with likely cause, scope, and next steps.
SKILL.md
| 1 | # Alert investigation |
| 2 | |
| 3 | You are investigating a specific triggered alert. Alerts arrive with structured context — an alert ID, name, threshold, value that crossed it, and a time range. Your job is to explain *why* it fired, assess *scope*, and recommend *action*. |
| 4 | |
| 5 | ## Prerequisites |
| 6 | |
| 7 | This skill uses the following LaunchDarkly observability MCP tools: |
| 8 | |
| 9 | - `query-logs` — query log records |
| 10 | - `query-traces` — query distributed traces |
| 11 | - `query-error-groups` — query error groups |
| 12 | - `query-sessions` — query sessions |
| 13 | - `query-aggregations` — query aggregated/time-bucketed metrics |
| 14 | - `get-keys` — discover available attribute keys before filtering |
| 15 | |
| 16 | ## Workflow |
| 17 | |
| 18 | 1. **Parse the alert context.** The first turn of the conversation carries alert variables: `alertID`, `alertName`, `alertValue`, `group`, `groupValue`, `query`, `thresholdWindow`, `timeRange`, plus a product-specific link. Use these, don't re-derive them. |
| 19 | 2. **Load the per-product companion.** Based on the alert's product type, load the matching companion: `logs.md`, `traces.md`, `errors.md`, `sessions.md`, or `metrics.md`. Each captures the per-product investigation shape. |
| 20 | 3. **Run the investigation** using the methodology from the investigate skill (cross-reference logs/traces/errors/sessions/metrics; cite identifiers; aggregate before paginating). Scoped to the alert's time range and filter. |
| 21 | 4. **Produce a structured diagnosis.** See output template below. |
| 22 | |
| 23 | ## Output template |
| 24 | |
| 25 | Alert investigations have a consistent structure so consumers (notification channels, dashboards) can parse them. |
| 26 | |
| 27 | ``` |
| 28 | ## What triggered |
| 29 | |
| 30 | <1-2 sentences naming the alert, the threshold, and the value that crossed it.> |
| 31 | |
| 32 | ## Likely cause |
| 33 | |
| 34 | <Root-cause narrative citing specific evidence: trace IDs, log timestamps, error group IDs, flag keys, deploy timing.> |
| 35 | |
| 36 | ## Scope |
| 37 | |
| 38 | <Who or what is affected. Number of users, services, sessions, error groups. Time window of impact.> |
| 39 | |
| 40 | ## Next steps |
| 41 | |
| 42 | <1-3 concrete actions the on-call or owner should take. Prefer specifics: "roll back flag X in env Y", "restart service Z", "investigate trace <id> for the downstream failure". Avoid "investigate further" — if you don't have a root cause, say what specifically should be investigated and how.> |
| 43 | ``` |
| 44 | |
| 45 | ## When to load which companion |
| 46 | |
| 47 | - **`logs.md`** — log alert, log pattern alert |
| 48 | - **`traces.md`** — latency alert, trace-error-rate alert, span-specific alert |
| 49 | - **`errors.md`** — error-rate alert, new-error-group alert, crash-rate alert |
| 50 | - **`sessions.md`** — session-health alert, user-facing-error-rate alert |
| 51 | - **`metrics.md`** — custom metric threshold, aggregated metric alert, composite alert |
| 52 | |
| 53 | If the alert crosses product boundaries (e.g. a metric alert driven by error data), load both companions. |
| 54 | |
| 55 | ## Guidelines |
| 56 | |
| 57 | - **Stay tight.** Alert investigations feed notifications — keep the output structured and scannable. No preamble ("Here is my analysis..."), no repeated framing. |
| 58 | - **Cite identifiers.** Every claim in the diagnosis should reference a specific trace ID, error group ID, session ID, or log timestamp. |
| 59 | - **If the alert appears to be noise**, say so explicitly — "This alert fired because of <X>, but the underlying behavior is within normal variance because <Y>". Noise is a legitimate outcome; don't invent root causes. |
| 60 | - **Don't redo the investigation you just did.** The diagnosis output should let the on-call act without re-querying. |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
