Bug root-cause analysis prompt

When to use it

Use this when an unexpected production failure occurs and you need a structured, blame-free post-mortem document. Replace the incident details with your own stack traces, logs, and telemetry before distributing it to engineering stakeholders.

The prompt

## Role
Act as a staff reliability engineer. Apply rigorous diagnostic judgment while ensuring technical explanations remain clear to both engineers and cross-functional partners.

## Context
KitePay, a digital checkout platform, experienced a 27-minute payment processing outage on its primary API cluster. Error telemetry showed an abrupt spike in HTTP 504 Gateway Timeouts following the deployment of release v2.14.0. The release introduced an unindexed foreign key lookup in the `merchant_settlements` table during token authorization, exhausting the PostgreSQL connection pool. Rollback to v2.13.9 resolved the timeouts.

## Objective
Produce a complete root-cause analysis (RCA) explaining how the code change triggered database connection starvation, how the failure was mitigated, and how to prevent recurrence.

## Audience
The primary readers are backend engineers and engineering managers. Provide sufficient architectural detail to justify remediation work without unnecessary theoretical lectures.

## Requirements
A 400–600-word RCA document containing: an incident summary table; a sequential timeline of detection, response, and resolution; a technical root-cause breakdown using the 5 Whys framework; immediate remediations completed; and long-term preventive actions. Include explicit database query and index recommendations.

## Constraints
Do not invent unlisted infrastructure components, arbitrary latency numbers, customer compensation figures, or unverified service dependencies. Confine technical findings to the supplied database and connection pool failure. Clearly label speculative factors as unconfirmed assumptions.

## Tone & style
Be objective, blameless, and analytically precise. Use plain technical language, concise bullet points, and clear structural hierarchy. Avoid defensive phrasing, hand-waving, and vague assurances.

## Output format
Present the RCA document first with distinct markdown headers. Place the timeline and remediation owners in clean markdown tables. Conclude with a verification checklist detailing telemetry alerts and code review policies that must be audited.

## What to avoid
Avoid superficial conclusions such as "human error," unsupported claims about zero downtime, and omitting the specific database query mechanism that caused connection pooling failure.

## Success criteria
An engineering lead can read the document and explain the exact failure mechanism, verify why rollback restored service, and assign specific preventive work items.

## Clarifying questions
Ask up to three focused questions only if critical architectural information is missing. Otherwise proceed using the scenario facts, state your working assumptions, and outline telemetry checks needed to confirm the fix.

Why it works

• The scenario gives the model a concrete technical failure mechanism instead of letting it default to generic server crash tropes.
• The requirements mandate standard engineering artifacts like the 5 Whys analysis and a precise remediation timeline.
• The constraints prevent the model from hallucinating unrelated infrastructure flaws or missing metrics.
• The success criteria ensure the resulting report is immediately reviewable and actionable for technical leads.

Make it yours

Build a tailored version with PromptDeck by replacing the fictional scenario with your own incident telemetry, timestamps, and architectural stack. Keep the verification checklist so preventative engineering tasks are properly audited.