CI/CD Pipeline Failure Log Triage Prompt Template

This prompt is for DevOps engineers, platform teams, and release managers who need to reduce the time spent investigating CI/CD pipeline failures. It ingests a raw CI/CD job log and outputs a structured triage report that isolates the primary failure reason, categorizes it, and extracts the relevant log section. Use this prompt when a pipeline job fails and you need a fast, consistent first pass at diagnosis before a human engineer dives into the details. The ideal user has access to raw job logs and understands their pipeline's architecture but wants to skip the repetitive log-scrolling phase of every failure investigation.

This prompt is not a replacement for root cause analysis or a substitute for understanding your own build system. It is a triage accelerator that turns a noisy log into a structured signal. Do not use this prompt when the failure involves multiple interdependent jobs across different pipelines, when the log is truncated or incomplete, or when the failure is a novel pattern that requires deep architectural knowledge. The prompt works best on single-job failures with complete logs. For multi-service incidents, use the Multi-Service Error Correlation Prompt instead. For flaky test investigations, pair this prompt with the Flaky Test Error Pattern Extraction Prompt to separate infrastructure flakiness from genuine test non-determinism.

Before deploying this prompt into an automated pipeline workflow, validate its output against a set of known failure cases from your own CI/CD history. The most common production failure mode is misclassification of flaky infrastructure failures (e.g., network timeouts, disk pressure) as application errors. Build an eval harness that checks whether the failure category matches a human-labeled ground truth, and route low-confidence classifications to a human review queue. Start with a narrow set of pipeline types and expand coverage as you build confidence in the triage accuracy.

This prompt template is designed to be pasted directly into your AI harness, such as an internal CLI tool, a Slack bot, or an automated incident response workflow. It expects a raw CI/CD job log and a set of constraints that define your team's specific pipeline stages and failure taxonomy. The goal is to produce a consistent, machine-readable JSON output that isolates the primary failure, categorizes it, and extracts the most relevant log section, saving engineers from scrolling through thousands of lines of raw output.

textCopy
You are a CI/CD pipeline failure triage specialist. Your task is to analyze a raw job log, identify the primary failure, and output a structured JSON report.

[INPUT]
The raw CI/CD job log is provided below:

[RAW_JOB_LOG]

codeCopy

[CONTEXT]
The pipeline consists of the following sequential stages: [PIPELINE_STAGES].
The expected failure categories are: [FAILURE_CATEGORIES].

[CONSTRAINTS]
- Identify the single, primary failure that caused the job to abort. Do not report cascading or secondary errors.
- If the log is truncated or incomplete, set the 'failure_category' to 'INCOMPLETE_LOG' and explain why in the 'rationale'.
- If no clear failure is found, set the 'failure_category' to 'UNKNOWN' and set 'confidence' to 'low'.
- The 'relevant_log_section' must be a verbatim, unaltered copy of the most critical lines from the input log, not a summary.

[OUTPUT_SCHEMA]
Respond exclusively with a valid JSON object conforming to this schema:
{
  "failure_category": "string",
  "failure_stage": "string",
  "headline": "A one-sentence summary of the failure",
  "rationale": "A detailed explanation of why this is the primary failure, referencing specific log lines",
  "relevant_log_section": "string",
  "confidence": "high | medium | low"
}

[RISK_LEVEL]
This analysis is for informational triage. All critical fixes must be reviewed by a human before merging.

To adapt this template, replace the square-bracket placeholders with your specific pipeline configuration. For [PIPELINE_STAGES], provide a comma-separated list like install_deps, lint, unit_test, build_image, integration_test, deploy_staging. For [FAILURE_CATEGORIES], define a taxonomy that fits your environment, such as TEST_FAILURE, BUILD_ERROR, LINT_ERROR, INFRA_TIMEOUT, ARTIFACT_UPLOAD_FAILURE, PERMISSION_DENIED. The [RAW_JOB_LOG] placeholder should be replaced by your application code that fetches the log content from your CI/CD provider's API (e.g., GitHub Actions, GitLab CI, Jenkins). The output schema is intentionally strict to allow for direct parsing in downstream automation, such as automatically creating a Jira ticket or posting a summary to an incident channel. Before deploying, run this prompt against a golden dataset of known pipeline failures to calibrate the confidence levels and ensure the model correctly distinguishes between a TEST_FAILURE and a BUILD_ERROR when they occur in the same log.

This prompt is designed to be the first step in an automated pipeline triage system, not a standalone chat interface. The primary integration point is a webhook receiver or a CI/CD plugin (e.g., a Jenkins, GitLab CI, or GitHub Actions hook) that fires on job failure. The application harness captures the raw log, truncates it to a safe context window (e.g., the last 8,000 tokens), injects it into the [RAW_PIPELINE_LOG] placeholder, and sends the request to the LLM. The output is a structured JSON object containing failure_category, failure_summary, and relevant_log_snippet. This structured output is then parsed by the harness to update the pipeline status with a human-readable summary, route the failure to the correct on-call channel based on failure_category, and attach the isolated snippet to the incident ticket, saving the engineer from scrolling through thousands of log lines.

The harness must implement a strict validation layer on the model's JSON output. Use a JSON Schema validator to ensure the failure_category field is one of the predefined enums (e.g., test_failure, build_error, infra_timeout, lint_error, unknown). If the output fails validation, the harness should execute a single retry with a more forceful system instruction that includes the validation error. If the retry also fails, the harness must fall back to a failure_category of unknown and attach the full raw log to the ticket, preventing a silent automation failure. For high-risk deployment pipelines (e.g., production releases), the harness should route any unknown or low-confidence classification to a human triage queue rather than auto-resolving. Log every prompt request, response, validation result, and retry as structured metadata for an observability dashboard to track classification accuracy and model drift over time.

Model choice is critical for latency and cost. This task requires strong instruction-following and JSON mode, making GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro suitable for complex, multi-service failures. For simpler, high-volume pipelines, a smaller model like GPT-4o-mini or Claude 3 Haiku, fine-tuned on your specific log format and failure taxonomy, will reduce cost and latency. Do not use a generic chat model without JSON mode enforcement. The harness should set response_format to json_object (or the provider's equivalent) and use a low temperature (0.0–0.1) for deterministic triage. Implement a 30-second timeout to ensure the triage step doesn't become a bottleneck in the developer's feedback loop. Finally, never include secrets or API keys in the log context; the harness must pre-process the log to redact any sensitive environment variables or credentials before sending them to an external model API.