Retry Budget Exhaustion Escalation Decision Prompt

This prompt is designed for a single, high-stakes job: making an auditable escalation decision when a retry budget is fully consumed. It is not a retry prompt itself, nor is it a general-purpose error handler. Its sole purpose is to fire as the terminal step in a retry harness when retry_count >= max_retries or when the error budget burn rate exceeds a defined SLO threshold. The ideal user is a reliability engineer or AI platform architect embedding this prompt into a production gateway that sits between automated retry loops and human incident response queues. The prompt ingests structured telemetry—including the original request intent, the full error chain, and the current retry budget state—and produces a deterministic routing decision, not a creative fix.

Use this prompt inside a controlled harness that has already exhausted all automated recovery strategies, such as exponential backoff with jitter, token refreshes, and model fallback routing. The harness must provide the prompt with a strict [INPUT] payload containing the retry count, the final error code, the error budget remaining, and the original user intent. The prompt's output is a structured [OUTPUT_SCHEMA] that includes a severity classification (e.g., SEV1, SEV2, SEV3), a human notification target (e.g., on-call-sre, triage-queue, no-action), and a concise incident summary. This prevents the two most common production failure modes: infinite retry loops that waste compute and silent failures where a permanently stuck request is never seen by a human.

Do not use this prompt for transient errors that are likely to succeed with a simple retry, such as a 429 rate limit or a brief 503 unavailability. Those failures should be handled by dedicated retry prompts within the budget. This prompt is the escalation gate, and invoking it prematurely creates alert fatigue and unnecessary human toil. Before wiring this into your application, ensure your harness has a clear, configurable max_retries parameter and a mechanism for tracking the error budget burn rate. The next step is to define the [OUTPUT_SCHEMA] and [CONSTRAINTS] in the prompt template so that the routing decision is machine-readable and can trigger the correct PagerDuty or ServiceNow workflow without manual parsing.

This prompt template is the core decision engine for your retry exhaustion handler. It is designed to be invoked by your application's retry harness only after all configured retries for a given operation have failed. The prompt ingests structured telemetry from your retry infrastructure—including error codes, retry counts, and SLO burn rates—and produces a structured escalation decision. Do not use this prompt for transient errors that are still within their retry budget; it is specifically for the terminal state where the system must decide to page a human, route to a dead letter queue, or trigger a last-resort fallback.

textCopy
You are an SRE decision assistant. Your task is to analyze a retry budget exhaustion event and produce a structured escalation decision. You must not suggest further retries. Base your decision strictly on the provided telemetry.

[CONTEXT]
Operation ID: [OPERATION_ID]
Operation Description: [OPERATION_DESCRIPTION]
Error Budget Remaining: [ERROR_BUDGET_REMAINING]%
Current SLO Status: [SLO_STATUS]

[RETRY_TELEMETRY]
Total Retries Attempted: [TOTAL_RETRIES]
Retry Budget Limit: [RETRY_BUDGET_LIMIT]
Final Error Code: [FINAL_ERROR_CODE]
Final Error Message: [FINAL_ERROR_MESSAGE]
Retry Log Summary:
[RETRY_LOG_SUMMARY]

[CONSTRAINTS]
- Do not recommend any further automated retries.
- If the error is a client error (4xx except 429), the decision must be to route to a human for review.
- If the error budget remaining is below 5%, the incident severity must be classified as 'critical'.
- The fallback action must be a concrete, executable step, not a suggestion.

[OUTPUT_SCHEMA]
{
  "decision": "escalate_to_human" | "route_to_dlq" | "trigger_last_resort_fallback",
  "incident_severity": "critical" | "high" | "medium" | "low",
  "routing_target": "string (e.g., on-call pager duty schedule, dead letter queue ARN, fallback function URL)",
  "summary_for_operator": "A concise, one-paragraph summary of the failure, the retries attempted, and the reason for this escalation decision.",
  "fallback_action": "A specific, executable instruction for the system to perform if 'trigger_last_resort_fallback' is chosen, otherwise null."
}

To adapt this template, replace every square-bracket placeholder with live data from your retry infrastructure. The [RETRY_LOG_SUMMARY] should be a concise, structured log of each attempt, including timestamps, durations, and error codes. The [OUTPUT_SCHEMA] is a contract for your harness; parse the model's JSON response and use the decision field to control the next step in your workflow. For high-risk environments, always log the full prompt and completion for auditability, and consider a human-in-the-loop approval step before executing a trigger_last_resort_fallback action that could modify production state.

This prompt is designed to be called by a retry orchestration layer—not by an end user. The harness should invoke it only when a defined retry budget for a given operation has been exhausted. Before calling the prompt, the harness must assemble the required context: the operation ID, total retry count, error budget burn rate, current SLO status, and a summary of the errors encountered. This context is injected into the [RETRY_CONTEXT] placeholder. The prompt's output is a structured escalation decision, not a conversational reply, so the harness must parse the JSON output and act on the action field.

Implement a strict validation layer around the model's response. The output must conform to the defined [OUTPUT_SCHEMA], which includes an action enum of ESCALATE, DEFER, or DISCARD. If the model returns an invalid action or malformed JSON, the harness should log the raw output and default to a safe fallback—typically ESCALATE to a human on-call rotation. Never retry the escalation decision prompt itself without a dead-letter queue, as this can mask a systemic failure in the decision logic. Log the full prompt context, model response, and validation result as structured audit events for post-incident review.

For high-severity incidents, integrate the ESCALATE action directly with your incident management tool (e.g., PagerDuty, Opsgenie). The notification_routing field in the prompt's output should map to pre-configured service IDs or escalation policies in your harness. Avoid letting the model hallucinate email addresses or phone numbers; instead, have it reference logical routing keys that your application resolves. When the action is DEFER, the harness should schedule a re-evaluation after a cooldown period defined in the output's retry_after_seconds field, ensuring the system doesn't loop on a failing operation without a pause. For DISCARD, the harness must move the operation to a dead-letter queue with the full error context attached for later manual inspection.