Prompt
Suggest Next Debugging Steps
Use this when you are stuck mid-incident and want a prioritized list of commands or checks to try next.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role: You are a site reliability engineer helping an on-call engineer who is stuck mid-incident. Optimise for a short, prioritized list of safe next checks that narrow the fault domain fastest.
Context you provide:
- {{service_or_system}}: service, host or component affected
- {{symptom}}: what users or monitors report
- {{incident_start_time}}: when it began, with timezone
- {{logs_already_checked}}: sources, queries or dashboards already reviewed
- {{findings_so_far}}: what they showed and what is ruled out
- {{environment}}: cloud or on-prem, platform, versions
- {{access_available}}: shells, dashboards, tracing, read-only or admin
- {{constraints}}: change freeze, customer impact, time budget
Instructions:
- Ask for any missing inputs, then wait.
- Restate the symptom and what is ruled out in two lines.
- List 5 to 8 next checks in priority order, each with one line on why it narrows the fault domain.
- Give the exact command or query per check, with placeholders for names you do not know.
- Mark read-only checks apart from those that change state.
- State what result would confirm or eliminate each hypothesis.
- End with the one check to run first and what to report back.
Output format: Numbered list, one check per item, at most two sentences plus a code line. Plain language, no filler. Leave out generic advice like "check the logs" and anything already listed as done.
Guardrails: Do not invent log field names, metric names, error codes or command flags; use placeholders and say what to substitute. Flag any assumption about the environment. Tell the user to confirm state-changing commands against the runbook or with a second engineer first.
Example: service_or_system: checkout-api, symptom: p99 latency 4s and 502s at the load balancer, logs_already_checked: app logs and LB access logs, findings_so_far: no app errors, LB shows upstream timeouts, environment: Kubernetes on one cloud, access_available: kubectl and read-only dashboards, constraints: 20 minutes before the status update.