Circuit Breaker Logging Completeness Prompt

This prompt is for Site Reliability Engineers (SREs) and platform engineers who need to validate that circuit breaker implementations produce complete, traceable logs for every state transition. When a circuit breaker trips to OPEN, transitions to HALF_OPEN, or resets to CLOSED, the logs must capture the event, failure counts, cooldown timers, and the service context. Missing log data during these transitions turns a routine incident into a prolonged outage because on-call responders lack the evidence to determine what failed and whether recovery is safe. Use this prompt when you have raw log output from a failure injection test, a chaos engineering exercise, or a production incident review and you need a structured completeness report that flags gaps before they cause diagnostic dead ends.

The ideal input is a raw log segment spanning a known circuit breaker state transition, along with the expected state machine definition and the service identifier. The prompt works best when you can provide the exact time window of the transition, the circuit breaker configuration (thresholds, cooldown periods, half-open max requests), and the log aggregation query used to retrieve the output. Do not use this prompt for general log quality audits, performance profiling, or security log review—it is specifically designed to check whether state-transition telemetry is complete enough to support incident diagnosis. If you are evaluating alert rule accuracy, use the Alert Trigger Validation Prompt instead; if you are checking for PII leakage, use the PII Leakage Detection in Error Logs Prompt.

Before running this prompt, confirm that you have access to the raw log output and the circuit breaker's expected behavior specification. The prompt will produce a structured completeness report with a state-transition traceability matrix, gap flags for missing events or context, and a diagnostic sufficiency score. After receiving the output, review any flagged gaps against your observability pipeline configuration—many completeness failures originate in log sampling, retention filters, or misconfigured log levels rather than in the circuit breaker code itself. If the report identifies missing cooldown timer visibility or absent failure count context, prioritize adding those fields to your structured log schema before the next incident.

The following prompt template is designed to be copied directly into your AI harness, LLM playground, or automated evaluation pipeline. It instructs the model to act as an SRE auditor, systematically checking circuit breaker logs for missing state transitions, absent context fields, and traceability gaps. Before running, replace every square-bracket placeholder with your actual data—this is not a fill-in-the-blanks exercise but a wiring step that connects the prompt to your real observability signals.

textCopy
You are an SRE auditing circuit breaker logging completeness for a service. Your task is to analyze the provided log excerpts and configuration to determine whether all circuit breaker state transitions are fully logged with sufficient diagnostic context.

## INPUT
- Log Excerpts: [LOG_EXCERPTS]
- Circuit Breaker Configuration: [CIRCUIT_BREAKER_CONFIG]
- Expected State Transition Diagram: [STATE_TRANSITION_DIAGRAM]
- Service Topology Context: [SERVICE_TOPOLOGY]

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "audit_summary": {
    "total_transitions_expected": <number>,
    "total_transitions_logged": <number>,
    "completeness_score": <0.0 to 1.0>,
    "overall_verdict": "COMPLETE" | "PARTIAL" | "INCOMPLETE"
  },
  "state_transition_checks": [
    {
      "transition": "CLOSED_TO_OPEN" | "OPEN_TO_HALF_OPEN" | "HALF_OPEN_TO_CLOSED" | "HALF_OPEN_TO_OPEN" | "OPEN_TO_CLOSED",
      "logged": true | false,
      "timestamp_present": true | false,
      "failure_count_context_present": true | false,
      "cooldown_timer_visible": true | false,
      "upstream_service_identified": true | false,
      "correlation_id_present": true | false,
      "log_level_appropriate": true | false,
      "evidence": "<quote from logs or 'NOT FOUND'>",
      "gap_description": "<explain what is missing, or null if complete>"
    }
  ],
  "traceability_gaps": [
    {
      "gap_type": "MISSING_TRANSITION" | "MISSING_CONTEXT" | "BROKEN_CORRELATION" | "AMBIGUOUS_STATE",
      "severity": "HIGH" | "MEDIUM" | "LOW",
      "description": "<explain the gap>",
      "recommendation": "<specific fix>"
    }
  ],
  "diagnostic_readiness_score": <0.0 to 1.0>
}

## CONSTRAINTS
- Only report on transitions that should exist based on the provided state transition diagram.
- If a transition is not logged at all, mark all context fields as false and explain the gap.
- Do not infer transitions that are not evidenced in the logs.
- Flag any log line where the circuit breaker state is ambiguous or contradictory.
- If the cooldown timer is configured but not visible in half-open transition logs, treat this as a HIGH severity gap.
- If failure count context is missing from an OPEN transition, treat this as a HIGH severity gap.

## EVALUATION CRITERIA
- Completeness: Are all expected state transitions present in the logs?
- Context Richness: Does each transition log carry failure counts, cooldown status, and upstream identifiers?
- Traceability: Can each transition be correlated to a specific request or incident via correlation IDs?
- Diagnostic Readiness: Would an on-call responder understand the circuit state timeline from these logs alone?

## RISK_LEVEL: [RISK_LEVEL]

Analyze the logs and return the JSON output.

To adapt this template, replace [LOG_EXCERPTS] with the actual log lines you want to audit—ideally a time-bounded window covering at least one full circuit breaker lifecycle. [CIRCUIT_BREAKER_CONFIG] should include your threshold values (e.g., failure count, cooldown seconds, half-open max requests) so the model can validate whether logged context matches configured behavior. [STATE_TRANSITION_DIAGRAM] can be a textual description of allowed transitions (e.g., 'CLOSED → OPEN on threshold breach, OPEN → HALF_OPEN after cooldown, HALF_OPEN → CLOSED on success, HALF_OPEN → OPEN on failure'). [SERVICE_TOPOLOGY] provides the upstream/downstream service names the model should expect to see in log attributes. Set [RISK_LEVEL] to HIGH if this audit is part of an incident postmortem or compliance review—this signals the model to apply stricter gap severity and recommend human review of its findings.

Before integrating this prompt into a production pipeline, validate the output against a known set of complete and incomplete log samples. A common failure mode is the model reporting transitions as 'logged' when only a partial log line exists without the required context fields. To guard against this, run the prompt against a golden dataset where you have manually labeled each transition's completeness and compare the model's verdicts. If the audit is part of a CI/CD gate for observability standards, route HIGH severity traceability gaps to a human reviewer before blocking a release. Do not treat the model's completeness score as a single source of truth without spot-checking the evidence quotes it extracts.

This prompt is designed to be integrated into a continuous validation pipeline, not run as a one-off manual check. The primary integration point is a post-deployment or pre-release audit step where structured log output from a circuit breaker library (e.g., resilience4j, Polly, or a custom implementation) is collected during a controlled failure injection test. The application harness should capture logs from the service under test, format them as a JSON array of log entries, and inject them into the [LOG_ENTRIES] placeholder. The [CIRCUIT_BREAKER_CONFIG] placeholder expects a structured object defining the expected breaker name, failure threshold, and cooldown period to ground the completeness check in the actual configuration.

The harness must enforce a strict validation loop. Before calling the model, validate that the input log array is not empty and contains at least one timestamped entry. After receiving the model's JSON output, validate it against the expected schema: a state_transition_trace array with from_state, to_state, timestamp, and log_evidence fields, plus a completeness_report object with boolean flags for open_event_logged, close_event_logged, half_open_event_logged, failure_count_context_present, and cooldown_timer_visible. If schema validation fails, retry once with a repair prompt that includes the validation error. For high-reliability pipelines, implement a human review gate when the completeness_report flags any missing events, routing the audit to an on-call channel before a release can proceed.

Model choice matters here. Use a model with strong JSON mode and structured output support (e.g., GPT-4o, Claude 3.5 Sonnet) because the state-transition traceability check requires precise temporal reasoning across log lines. Set temperature to 0 to minimize variance in audit results. For CI integration, wrap the prompt call in a script that exits with a non-zero code when critical events are missing, allowing the audit to block a deployment pipeline. Avoid running this prompt on production log streams without sampling; a single circuit breaker instance can generate thousands of state transitions under load, and the model context window should be reserved for a focused window around the injected failure test.