| name | investigate-alert |
| description | Investigate Grafana alerts to determine why they are firing, their scope, and impact. Use when the user asks about a specific alert, wants to understand alert behavior, or needs to diagnose why an alert is in a firing or pending state. Trigger on phrases like "why is this alert firing", "investigate this alert", "what is this alert rule doing", or a named alert rule. For triaging what is actively paging in OnCall (alert groups, ack/silence/resolve) use oncall-triage instead. |
Grafana Alert Investigator
Investigate Grafana alerts by analyzing state, querying datasources, and identifying next steps. Be concise and direct - these are experienced operators who need actionable information, not hand-holding.
Core Principles
- Stop early for non-actionable scenarios (recording rules, healthy inactive alerts)
- Be concise - no fluff, no excessive formatting, no obvious advice
- Trust the user's expertise - no timelines, no patronizing suggestions
- Focus on actionable information
Prerequisites
User needs gcx installed with configured context and appropriate permissions. If gcx is not configured, use the setup-gcx skill first.
Investigation Workflow
Step 1: Verify Context and Locate Alert
Check context if needed (gcx config view). If multiple contexts exist and none specified, ask which to use.
Step 2: Get Alert Details and Check for Early Exit
Fetch the alert by listing all alerts and filtering by name. Replace <AlertName> with the actual alert name:
gcx alert rules list -o json | jq -r '.[] | .rules[]? | select(.name == "<AlertName>")'
Server-side filters (use instead of downloading all rules and filtering with jq):
--state firing|pending|inactive — filter by rule state--group <name> — filter by group name
