Test Environment Health Check Flakiness Prompt

This prompt is designed for platform engineers and test infrastructure teams who need to validate environment health before a test suite runs. Its primary job is to analyze structured telemetry—resource availability, service reachability, configuration consistency, and clock synchronization—to predict flakiness risk. Use it as a pre-flight gate in CI/CD pipelines, nightly test runs, or on-demand environment provisioning. The ideal user is someone who owns the reliability of the test infrastructure itself, not the application code under test. They need a clear, structured health report with a go/no-go recommendation and preemptive remediation steps, not a raw log dump.

The prompt requires structured environment telemetry as input. This means feeding it a JSON or YAML object containing key-value pairs for CPU/memory/disk usage, service endpoint status codes, configuration checksums, and NTP offset values. It is not designed to parse unstructured logs or raw monitoring dashboards. The output is a machine-readable health report with explicit fields for each health dimension, a calculated risk score, and a boolean go_no_go recommendation. This structure allows you to wire the prompt directly into an automated pipeline gate. If the go_no_go field is false, the report includes a list of remediation_steps that can be surfaced to the on-call engineer or used to trigger an automatic provisioning script.

Do not use this prompt as a replacement for runtime monitoring or post-failure root cause analysis. It is a point-in-time check, not a continuous observer. It will not catch a network partition that occurs mid-test-run or a gradual memory leak. For those scenarios, use the sibling prompts on 'Network Timeout Flakiness Triage' or 'CI Pipeline Failure Signal Isolation'. Furthermore, avoid using this prompt when you lack structured telemetry; feeding it raw logs will produce unreliable, often hallucinated, health assessments. The next step after reading this section is to instrument your environment to produce the required structured input, then use the prompt template in the following section to build your first health check gate.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a platform reliability engineer performing a pre-flight environment validation. The model will analyze a set of health indicators you provide and produce a structured go/no-go recommendation. All square-bracket placeholders must be replaced with real data from your environment before execution.

markdownCopy
You are a platform reliability engineer performing a pre-flight environment health check before a test execution run. Your goal is to predict the risk of flaky test failures caused by environmental instability.

Analyze the following environment health indicators and produce a structured health report.

## Environment Health Indicators
[ENVIRONMENT_HEALTH_INDICATORS]

## Test Suite Context
[TEST_SUITE_CONTEXT]

## Constraints
- Classify each indicator as HEALTHY, DEGRADED, or UNHEALTHY.
- If any indicator is UNHEALTHY, the overall recommendation must be NO-GO.
- If two or more indicators are DEGRADED, the overall recommendation must be NO-GO.
- Provide specific, actionable remediation steps for every non-healthy indicator.
- Do not speculate about code defects; focus strictly on environment stability.

## Output Schema
Return a single valid JSON object with this exact structure:
{
  "overall_recommendation": "GO" | "NO-GO",
  "risk_level": "LOW" | "MEDIUM" | "HIGH",
  "indicator_assessments": [
    {
      "indicator_name": "string",
      "status": "HEALTHY" | "DEGRADED" | "UNHEALTHY",
      "observed_value": "string",
      "expected_value": "string",
      "evidence": "string",
      "remediation_steps": ["string"]
    }
  ],
  "summary": "string"
}

To adapt this prompt, replace [ENVIRONMENT_HEALTH_INDICATORS] with a structured list of your environment's key metrics: resource availability (CPU, memory, disk), service reachability (health check endpoints, port connectivity), configuration consistency (environment variables, feature flags across nodes), and clock synchronization (NTP offset). Replace [TEST_SUITE_CONTEXT] with a brief description of the test suite about to run, including its resource profile and critical dependencies. For high-risk production environments, always route the model's output through a human review step before taking remediation actions or overriding a NO-GO recommendation.

This prompt is designed to run as a pre-flight gate before a test suite executes, not as a post-mortem analysis tool. The ideal integration point is a CI pipeline stage that runs after environment provisioning but before test execution begins. The prompt consumes structured environment telemetry—not raw logs—so you must build a thin collector that gathers the required inputs (resource metrics, service reachability, configuration diffs, clock skew) and formats them into the [ENVIRONMENT_TELEMETRY] block. The model's output is a structured health report with a go/no-go recommendation and a list of preemptive remediation steps. If the recommendation is no-go, the pipeline should halt and surface the remediation steps to the on-call channel before tests waste compute on a known-bad environment.

Validation and retry logic is critical here because a false no-go blocks the pipeline, and a false go lets flaky tests waste engineering time. Implement a JSON schema validator on the model's output to ensure the recommendation field is exactly go or no-go and that each remediation_step includes a non-empty action and target field. If validation fails, retry once with the same input and a stricter [CONSTRAINTS] block that says: Output only valid JSON matching the schema. Do not add commentary. If the second attempt also fails validation, fail the pipeline stage open or closed based on your risk tolerance—document this fallback behavior in your runbook. For high-risk environments (production-like staging, compliance-bound systems), route no-go outputs to a human reviewer via a Slack or PagerDuty integration before blocking the pipeline. The reviewer can override the recommendation if the model misclassified a transient blip as a systemic failure.

Model choice and latency budget matter. This prompt requires reasoning over multiple environment signals and producing a structured recommendation, so use a model with strong JSON mode and instruction-following (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that may hallucinate remediation steps or misclassify borderline cases. Set a timeout of 15–30 seconds for the API call; if the model doesn't respond in time, treat it as a no-go with the remediation step "action": "manual_health_check", "target": "environment_validation_timeout". Log every invocation—input telemetry, model output, validation result, and final pipeline decision—to a structured logging system (e.g., Datadog, Splunk, or your CI's artifact store). This log becomes the audit trail when a flaky test escapes and you need to determine whether the environment health check missed it or was never run.

Do not use this prompt as a substitute for deterministic health checks. If you can verify a condition with a simple script (e.g., curl for service reachability, ntpstat for clock sync), do that first and include the result in the telemetry block. The model adds value by synthesizing multiple weak signals into a holistic risk assessment—something a threshold-based script cannot do. But it should not be the sole gatekeeper for binary conditions. Wire the prompt as the final reasoning layer on top of deterministic checks, not as the first line of defense.