Timeout and Deadline Configuration Prompt

This prompt is for backend engineers and SREs who need to audit timeout and deadline configurations across a distributed system. The primary job-to-be-done is producing a timeout budget analysis that identifies mismatched deadlines, missing propagation headers, and resource leak risks. The ideal user has access to the service call graph, including each service's configured timeouts and whether deadline propagation is implemented. Use this prompt before a new service launch to prevent latent timeout bugs, during scheduled resilience reviews to validate end-to-end guarantees, or when investigating timeout-related production incidents where requests are abandoned or resources are exhausted.

The prompt assumes you can provide a description of the call graph. This includes the sequence of service-to-service calls, the configured timeout at each hop, and whether the system passes a deadline context (such as gRPC deadlines or custom trace headers) between services. Without this data, the analysis will be speculative. If you only have partial data, the prompt will flag gaps and recommend instrumentation before proceeding. Do not use this prompt for simple single-service timeout tuning, for latency optimization without deadline analysis, or when the system uses fire-and-forget patterns where deadlines are intentionally absent.

After running the prompt, you will receive a structured analysis that maps the end-to-end deadline budget, identifies services where local timeouts exceed the remaining budget, flags missing propagation points, and highlights resource leak risks where abandoned work continues beyond the client's deadline. The next step is to validate the findings against your actual configuration, implement the recommended fixes, and rerun the analysis to confirm the budget closes. Avoid treating this as a one-time check; rerun it whenever the call graph changes or new services are added.

This prompt template is designed to be pasted directly into your AI workspace. It instructs the model to act as a distributed systems reliability reviewer, analyzing a provided service architecture description for timeout and deadline misconfigurations. The model will produce a structured timeout budget analysis, identifying mismatched deadlines, missing propagation, and resource leak risks. Replace the square-bracket placeholders with your specific system details before execution.

textCopy
You are a principal reliability engineer reviewing the timeout and deadline configuration for a distributed system. Your goal is to prevent resource exhaustion, abandoned requests, and cascading failures caused by misconfigured timeouts.

## System Context
[SERVICE_ARCHITECTURE_DESCRIPTION]
- Include service names, their dependencies, and the critical path for a key request flow.
- For each service-to-service call, provide the configured connection timeout, request timeout, and any deadline propagation headers used (e.g., `grpc-timeout`, custom `X-Deadline`).

## Analysis Constraints
- [CONSTRAINTS]
- Example: "The system uses gRPC for all internal communication. The client-facing API gateway has a strict 1500ms SLA."
- Example: "Database calls are wrapped in a circuit breaker with a 5-second timeout."

## Output Schema
Produce a JSON object with the following structure:
{
  "analysis_summary": "A one-sentence summary of the overall health of the timeout configuration.",
  "budget_breakdown": [
    {
      "hop": "Service A -> Service B",
      "allocated_budget_ms": 200,
      "cumulative_budget_ms": 400,
      "status": "OK" | "WARNING" | "CRITICAL",
      "finding": "Description of the issue or confirmation of correct configuration."
    }
  ],
  "critical_findings": [
    {
      "type": "MISMATCHED_DEADLINE" | "MISSING_PROPAGATION" | "RESOURCE_LEAK_RISK" | "UNBOUNDED_WAIT",
      "severity": "HIGH" | "MEDIUM",
      "location": "Service X -> Service Y",
      "description": "Detailed explanation of the risk.",
      "remediation": "Specific, actionable step to fix the configuration."
    }
  ],
  "end_to_end_compliance": {
    "client_sla_ms": 1500,
    "worst_case_cumulative_timeout_ms": 1800,
    "compliant": false,
    "overflow_hop": "Service C -> Service D"
  }
}

## Evaluation Criteria
- Every service-to-service call in the critical path must be accounted for in the budget breakdown.
- A WARNING must be raised if a downstream timeout is greater than or equal to an upstream caller's timeout.
- A CRITICAL finding must be raised if a deadline propagation header is not forwarded to a downstream dependency.
- A RESOURCE_LEAK_RISK must be raised if a service has no configured timeout for a blocking I/O call.
- The end-to-end compliance check must sum the worst-case timeouts along the critical path and compare it to the client SLA.

## Risk Level
[RISK_LEVEL: HIGH]
- If HIGH, include a final note that a human SRE must review and approve any configuration changes before deployment to production.

To adapt this template, replace the [SERVICE_ARCHITECTURE_DESCRIPTION] with a detailed, text-based representation of your call graph. The [CONSTRAINTS] placeholder should be filled with specific technology choices (e.g., gRPC, REST) and organizational policies (e.g., a 99th percentile latency SLO). The [RISK_LEVEL] flag controls the inclusion of a mandatory human-review step in the prompt's instructions, which is critical for production configuration changes. After pasting the prompt, the model will output a JSON object that you can parse and use to drive automated configuration checks in your CI/CD pipeline.

This prompt is designed to be called programmatically as part of a design review pipeline, not as a one-off chat interaction. The primary integration point is a CI check that runs when service configuration files (e.g., timeout-config.yaml, service-mesh.json, or application.properties) are modified in a pull request. The harness should extract the relevant timeout and deadline configurations from the changed files, assemble them into the [SERVICE_TIMEOUT_CONFIG] input block, and invoke the model. The output is a structured JSON report that downstream tooling can parse to block merges, file tickets, or update a design review dashboard.

Validation and retry logic is critical because the prompt produces a structured JSON output with a known schema. Implement a JSON schema validator that checks for required fields (timeout_budget_analysis, mismatched_deadlines, propagation_gaps, resource_leak_risks, overall_risk_score) and correct types before accepting the response. If validation fails, retry up to two times with the same input but append the validation error message to the prompt as a [PREVIOUS_ERROR] constraint. After three failures, escalate to a human reviewer via a ticket with the raw model output and validation errors attached. For high-risk services (payment processing, auth, health data), always require human approval on the final report regardless of validation success.

Model selection matters for this task. Use a model with strong structured output capabilities and a context window large enough to hold multiple service configurations plus the analysis output. GPT-4o, Claude 3.5 Sonnet, or equivalent models work well. Avoid smaller or older models that may hallucinate deadline values or produce malformed JSON under the schema constraints. Set the temperature to 0 or very low (0.1) to maximize consistency across runs. Logging should capture the input configuration hash, model version, output schema validation result, retry count, and final risk score for auditability. Store these logs alongside the PR or design review record so that teams can trace why a timeout budget was flagged as high-risk six months later.

Tool integration is optional but powerful. If your organization maintains a service catalog or CMDB, wire the harness to enrich the [SERVICE_TIMEOUT_CONFIG] input with upstream and downstream dependency data before calling the model. This gives the prompt a more complete picture of the call chain. After the model returns its analysis, use a post-processing step to compare detected risks against known incident records or past postmortems—this can surface recurring timeout misconfigurations that the model alone might not flag as systemic. What to avoid: do not wire this prompt directly into an auto-remediation pipeline that changes timeout values without human review. The model identifies risks and suggests ranges, but production timeout changes require load testing, canary validation, and SRE approval.