Health Check Endpoint Design Audit Prompt

This prompt is for platform engineers and SREs who need to audit the design of health check endpoints—liveness, readiness, and startup probes—before they ship to production. It is not a generic code review prompt. The job-to-be-done is a structured, pre-deployment design audit that identifies shallow checks, missing dependency ordering, misconfigured timeouts, and false-positive risks. These defects, if left undetected, can cause cascading failures during partial outages or slow-start rejections during deployments. The prompt assumes you have a probe specification, a dependency graph, or a configuration snippet to analyze. Use it during design review, as part of a pre-deployment checklist, or when preparing resilience tests.

To use this prompt effectively, you must provide concrete design artifacts. The required input includes a description of the service's runtime dependencies (databases, caches, upstream APIs, message brokers), the current or proposed probe configurations (endpoint paths, HTTP methods, timeout values, interval and threshold settings), and the expected startup sequence. The prompt produces a structured audit report that flags specific risks: a liveness probe that only checks if the process is running without verifying internal state, a readiness probe that returns 200 OK before the database connection pool is initialized, or a startup probe timeout that is shorter than the actual warm-up duration. Each finding includes a severity rating and a concrete remediation recommendation.

Do not use this prompt for runtime incident diagnosis. If a service is already failing in production, this design-time audit will not help you triage the active incident. Instead, use an operational incident or runbook prompt from the resilience pillar. Similarly, do not use this prompt as a substitute for load testing or chaos engineering; it audits the static configuration, not the dynamic behavior under stress. Finally, this prompt is not a general code quality reviewer—it focuses narrowly on health check endpoint design and its interaction with orchestration systems like Kubernetes, Nomad, or ECS. If you need a broader resilience review, combine this prompt with the circuit breaker, retry policy, or graceful degradation prompts in the same content group.

This prompt template is designed to be pasted directly into your AI workflow. It expects you to provide a detailed description of your health check endpoint design, including liveness, readiness, and startup probe configurations, a dependency map of your services, and the platform context in which these checks run. The model will then produce a structured audit identifying risks such as false positives, cascading failures, and slow-start scenarios. Before using this prompt, ensure you have documented your probe configurations and understand your service's critical dependencies.

textCopy
You are an SRE architect auditing health check endpoint designs for resilience gaps. Your task is to review the provided probe configuration, dependency map, and platform context to produce a structured audit.

## INPUT
[PROBE_CONFIGURATION]
[DEPENDENCY_MAP]
[PLATFORM_CONTEXT]

## AUDIT CRITERIA
Analyze the input against the following criteria:
1.  **Check Depth:** Do liveness checks verify only the application process, or do they inadvertently test dependencies? Do readiness checks include all critical downstream and upstream dependencies? Do startup checks wait for all necessary resources (e.g., cache warm-up, DB migration) before marking the pod as ready?
2.  **Dependency Ordering:** Is there a risk of a dependency loop or a cascading failure where a readiness check on Service A depends on Service B, whose readiness check depends on Service A? Identify any missing or misordered dependencies.
3.  **Timeout and Interval Configuration:** Are the `timeoutSeconds`, `periodSeconds`, `failureThreshold`, and `successThreshold` values appropriate for the dependency's latency profile? Flag configurations where a slow-starting dependency could cause a probe timeout and a premature restart loop.
4.  **False-Positive Risks:** Identify scenarios where a probe could report a false positive (e.g., a liveness check that only verifies a local file exists) or a false negative (e.g., a readiness check that fails because a non-critical cache is temporarily unavailable).
5.  **Cascading Failure Analysis:** Model a scenario where a critical downstream dependency fails. Trace how the failure would propagate through the readiness checks of dependent services, potentially causing a system-wide restart storm.

## OUTPUT_SCHEMA
Return a JSON object with the following structure. Do not include any text outside the JSON object.
{
  "audit_summary": "A one-sentence summary of the overall health check design's resilience.",
  "findings": [
    {
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "category": "Check Depth | Dependency Ordering | Timeout Configuration | False Positive Risk | Cascading Failure",
      "affected_component": "The specific probe or service name.",
      "description": "A clear, concise description of the finding.",
      "risk": "The operational risk if this finding is not addressed.",
      "recommendation": "A specific, actionable recommendation to fix the issue."
    }
  ],
  "dependency_graph_analysis": {
    "cycles_detected": ["List of any dependency cycles found, e.g., 'Service A -> Service B -> Service A'"],
    "single_points_of_failure": ["List of dependencies that, if they fail, would cause a cascading readiness failure across multiple services."]
  },
  "slow_start_risk_assessment": "An assessment of the risk that a service with a long initialization time will be killed by Kubernetes during startup due to probe configuration."
}

## CONSTRAINTS
- Base your analysis strictly on the provided [PROBE_CONFIGURATION], [DEPENDENCY_MAP], and [PLATFORM_CONTEXT]. Do not invent dependencies or configurations.
- If the input lacks sufficient detail to assess a criterion, note it as an 'UNKNOWN' risk with a recommendation to gather more information.
- Prioritize findings that could lead to production outages or restart storms.

To adapt this template, replace the [PROBE_CONFIGURATION], [DEPENDENCY_MAP], and [PLATFORM_CONTEXT] placeholders with your specific data. The [PROBE_CONFIGURATION] should be a detailed YAML or JSON snippet of your Kubernetes probes or equivalent health check definitions. The [DEPENDENCY_MAP] should be a clear list or diagram description of how your services call each other. The [PLATFORM_CONTEXT] should describe the orchestration platform (e.g., Kubernetes, Nomad) and any relevant operational constraints. The output is a structured JSON object, making it suitable for direct ingestion into a dashboard or a secondary automated remediation workflow. For high-risk environments, always have a senior engineer review the AI-generated audit before implementing any changes.

The Health Check Endpoint Design Audit Prompt is designed to run as a pre-production design review gate, not as a runtime health check itself. Integrate it into pull request workflows, architecture review pipelines, or SRE design review checklists. The prompt expects a structured description of your health check configuration—including probe types, dependency graphs, timeout values, and failure thresholds—and returns an audit with prioritized findings. Wire it so that the prompt runs when a service definition, Helm chart, or infrastructure-as-code module containing health check configurations is modified.

Validation and retries: Parse the model's output against a lightweight JSON schema that enforces the expected structure: findings (array of objects with severity, category, description, affected_probe, and recommendation fields) and summary (object with risk_level and critical_findings_count). If the output fails schema validation, retry once with the validation error appended to the prompt as a correction hint. If the second attempt also fails, route to a human reviewer with the raw output and validation errors attached. Model choice: Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because the audit requires cross-referencing probe dependencies, timeout budgets, and cascading failure scenarios. Avoid smaller or faster models that may miss subtle false-positive risks in readiness probe configurations.

Logging and traceability: Store each audit result with the commit SHA, service name, timestamp, model version, and prompt version. This creates an audit trail for compliance reviews and lets you compare findings across service versions. Human review gate: For any finding with severity: critical—such as missing liveness probes, circular probe dependencies, or timeout configurations that guarantee false positives under load—require human acknowledgment before the PR can merge. For lower-severity findings, you can auto-approve but surface them in the PR comment thread. Tool use and RAG: If your health check configurations are spread across multiple repositories or configuration stores, use a retrieval step before the prompt to gather all relevant probe definitions, dependency maps, and deployment descriptors. Feed the retrieved context into the [INPUT] placeholder as structured YAML or JSON. Do not rely on the model to recall your organization's specific probe conventions or naming patterns—supply them in the prompt's [CONTEXT] section.

What to avoid: Do not run this prompt as a runtime health check—it is a design audit, not a monitoring tool. Do not skip the human review gate for critical findings; probe misconfiguration can cause cascading pod restarts, traffic blackholing, and failed rollouts. Do not use the audit output to automatically modify health check configurations without human approval. Finally, test the prompt against known failure scenarios (slow-start dependencies, circular probe chains, missing startup probes for stateful services) before deploying it as a required CI gate. Start with advisory mode and graduate to blocking only after you've measured false-positive and false-negative rates against human-reviewed baselines.