| name | groq-incident-runbook |
| description | Execute Groq incident response: triage, mitigation, fallback, and postmortem.
Use when responding to Groq-related outages, investigating errors,
or running post-incident reviews for Groq integration failures.
Trigger with phrases like "groq incident", "groq outage",
"groq down", "groq on-call", "groq emergency", "groq broken".
|
| allowed-tools | Read, Bash(kubectl:*), Bash(curl:*) |
| version | 1.11.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","groq","incident-response"] |
| compatibility | Designed for Claude Code |
Groq Incident Runbook
Overview
Rapid incident response procedures for Groq API failures. Groq is a third-party inference provider -- when it goes down, your mitigation options are: wait, fall back to a different model, or fall back to a different provider.
This SKILL.md is the high-level flow. Deep, copy-paste-ready material lives in references/:
Prerequisites
GROQ_API_KEY exported in the environment you run the triage commands from.curl for API probes; kubectl only if you collect logs from a Kubernetes deployment.- Access to console.groq.com to rotate keys or upgrade the plan.
- A configured fallback provider (e.g. OpenAI) if you need to fail away from Groq entirely.
Authentication: every Groq API call in this runbook authenticates with a bearer token — Authorization: Bearer $GROQ_API_KEY. Keep the key in a secret manager, never inline; the evidence-collection step in communication-and-postmortem.md redacts gsk_ tokens from logs before archiving.
Instructions
Work the incident in five phases. Each phase points to the reference file with the exact commands.
-
Classify severity. Match user impact to the P1–P4 table in
triage-and-diagnostics.md — this sets your response-time budget (P1 < 15 min, P4 next business day).
-
