Network Timeout Flakiness Triage Prompt

This prompt is designed for CI/CD engineers and test infrastructure engineers who need to triage network timeout failures that occur during automated test runs. The job-to-be-done is classification: given raw failure logs, network diagnostic output (such as ping, traceroute, dig, or curl timing data), and environment metadata from a failed build, the prompt instructs the model to identify the root cause category and produce an evidence-backed remediation plan. The ideal user has access to structured failure context and understands that the model is reasoning over network layers—DNS resolution, connection pool exhaustion, firewall rules, proxy misconfiguration, or remote service degradation—rather than application code paths. Use this prompt when a test fails with a timeout error and you have already ruled out application-level logic bugs, assertion failures, or performance regressions that do not involve network calls.

To use this prompt effectively, you must supply three categories of input: the raw failure log or error message from the test runner, network diagnostic output captured at the time of failure, and environment metadata including the test environment identifier, target service endpoints, and any relevant proxy or firewall configuration. The prompt template uses square-bracket placeholders for these inputs—[FAILURE_LOG], [NETWORK_DIAGNOSTICS], and [ENVIRONMENT_METADATA]—and expects you to populate them with concrete data before sending the request. The model will produce a structured triage output with a root cause category, supporting evidence extracted from the diagnostics, and specific remediation steps. Do not use this prompt for failures where the timeout is a symptom of an application hang, a deadlock, or a test logic error that happens to manifest as a timeout. The prompt assumes the failure originates in the network layer and will misclassify non-network timeouts if given misleading input.

Before relying on this prompt in production, validate its output against known failure cases where you have independently confirmed the root cause. Common failure modes include misclassifying DNS timeouts as remote service degradation when the diagnostic output is incomplete, or recommending retry strategies without considering whether the downstream service is idempotent. Always review the remediation steps before applying them to shared CI infrastructure, especially when the recommendation involves changing firewall rules, proxy configuration, or connection pool sizes. For high-severity failures in deployment pipelines, pair the model's output with human review and consider logging the triage result alongside the build artifact for auditability.

This prompt template is designed to be dropped into your triage workflow when a CI/CD pipeline reports a network timeout failure. It forces the model to classify the failure into one of six specific root cause categories—DNS resolution, connection pool exhaustion, firewall rules, proxy misconfiguration, remote service degradation, or unknown—rather than producing a vague summary. The template expects structured log evidence, environment metadata, and recent change history as inputs, and it outputs a strict JSON schema that your automation can parse directly.

textCopy
You are a network reliability engineer triaging a test timeout failure in a CI/CD pipeline. Your task is to classify the root cause of the timeout and recommend remediation steps.

## INPUT
Test failure log excerpt:
[FAILURE_LOG]

Environment metadata (runner type, region, container image, network config):
[ENVIRONMENT_METADATA]

Recent changes (code, config, infrastructure, dependency versions) within the last [CHANGE_WINDOW_HOURS] hours:
[RECENT_CHANGES]

Known service health status for external dependencies:
[SERVICE_HEALTH_STATUS]

## OUTPUT_SCHEMA
Return a single JSON object with these fields:
- "classification": one of "dns_resolution", "connection_pool_exhaustion", "firewall_rule", "proxy_misconfiguration", "remote_service_degradation", "unknown"
- "confidence": a float between 0.0 and 1.0
- "evidence": an array of strings quoting specific log lines, timestamps, or metadata fields that support the classification
- "alternative_hypotheses": an array of up to 2 other possible classifications with brief reasons
- "remediation_steps": an array of actionable steps ordered by likely impact
- "retry_strategy": an object with fields "max_retries" (integer), "backoff_multiplier" (float), "initial_delay_seconds" (integer), and "retry_conditions" (array of strings describing when a retry is appropriate)
- "requires_human_review": boolean, set true if confidence < 0.7 or classification is "unknown"

## CONSTRAINTS
- Do not fabricate log lines or evidence not present in the input.
- If the evidence is insufficient for a confident classification, set classification to "unknown" and confidence below 0.5.
- For "remote_service_degradation", cite specific error codes, latency spikes, or rate-limiting signals.
- For "connection_pool_exhaustion", cite pool size configs, connection wait times, or leaked connection patterns.
- Do not recommend production infrastructure changes without flagging requires_human_review as true.
- Prefer remediation steps that can be implemented in test configuration or CI pipeline settings before recommending service-level changes.

## EXAMPLES
Example input: "dial tcp 10.0.1.45:5432: i/o timeout after 30s" with no DNS errors and pool config showing max_connections=5.
Example output classification: "connection_pool_exhaustion" with evidence pointing to pool saturation.

Example input: "lookup service.internal on 169.254.169.254:53: no such host" with recent VPC peering change.
Example output classification: "dns_resolution" with evidence pointing to DNS propagation delay after network change.

To adapt this template for your environment, replace the [CHANGE_WINDOW_HOURS] placeholder with a default value appropriate for your deployment frequency—typically 24 hours for daily CI pipelines, or 4 hours for high-frequency merge queues. The [SERVICE_HEALTH_STATUS] field should be populated from your monitoring system's API before the prompt is assembled; if you lack automated health checks, replace it with a manual status note or omit the field and remove the corresponding constraint. The output schema is intentionally strict to enable automated parsing: your harness should validate that classification matches the enum, confidence is a float, and requires_human_review is true when confidence falls below 0.7. If the model returns a classification of "unknown" with high confidence, that is a valid signal that your logging or observability coverage has a gap worth investigating.

Integrating this prompt into an application requires building a harness that collects the right evidence before calling the model and validates the output before acting on it. The prompt expects structured failure context—timing data, DNS resolution results, connection pool metrics, proxy logs, and remote service status—so your harness must aggregate these signals from CI artifacts, monitoring dashboards, and infrastructure APIs. A common pattern is to trigger the prompt from a webhook that fires when a test run exceeds a configurable timeout failure threshold, then enrich the raw failure event with the additional context the prompt requires. Without this enrichment step, the model will produce low-confidence classifications or hallucinate evidence it cannot see.

The output schema demands a specific triage category, evidence list, and remediation steps. Implement a post-processing validator that checks: (1) the triage_category field matches one of the allowed enum values (DNS_RESOLUTION, CONNECTION_POOL_EXHAUSTION, FIREWALL_RULE, PROXY_MISCONFIGURATION, REMOTE_SERVICE_DEGRADATION, or UNCLASSIFIED), (2) each evidence item includes a source field pointing to a real log line or metric, and (3) remediation steps are non-empty and actionable. If validation fails, retry once with the same prompt but append the validator's error message as a [CORRECTION_HINT]. After two failed attempts, route to a human triage queue rather than silently accepting a malformed classification. For model selection, use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to minimize variance in classification decisions. Log every prompt input, model response, and validation result for auditability—this is critical when the classification drives automated retry policy changes or infrastructure remediation.

The highest-risk path is automated remediation based on the model's output. Never allow the model's suggested retry strategy or firewall rule change to execute without human approval when the classification confidence is below a defined threshold or when the remediation involves production infrastructure changes. Implement a confidence gate: if the model's confidence_score field (which you should add to the output schema) falls below 0.85, or if the triage category is UNCLASSIFIED, route to a human reviewer with the full evidence package. For lower-risk actions like adjusting test-level retry counts or quarantining a single test, automated application is reasonable provided the action is reversible and logged. Avoid wiring this prompt directly to infrastructure-as-code systems or firewall management APIs without an explicit approval step—misclassification of a DNS issue as a firewall problem could trigger an unsafe rule change.