CI/CD Pipeline Failure Correlation Prompt

Use this prompt when an incident is active or under post-incident review and you suspect a recent pipeline event—such as a failed build, flaky test regression, artifact change, or deployment rollback—may be a contributing factor or early signal. The ideal user is a DevOps engineer, SRE, or on-call responder who has access to a structured incident window and a list of pipeline events from systems like Jenkins, GitHub Actions, GitLab CI, or Spinnaker, but lacks the time to manually cross-reference every event against the incident timeline. The prompt ingests these two datasets and outputs a ranked list of pipeline events correlated with the incident, each with a correlation strength score, evidence summary, and a recommended action.

This prompt is not a replacement for metric dashboards, distributed tracing tools, or log aggregation platforms. It does not perform real-time monitoring or execute diagnostic commands. Instead, it acts as a reasoning accelerator that helps you quickly narrow a large set of pipeline events to the few most likely to be relevant. You should use it when the incident's symptoms suggest a deployment-related cause—such as a sudden spike in errors immediately following a release—but the exact trigger is unclear because dozens of pipeline events occurred in the same window. The prompt requires a well-formed [INCIDENT_WINDOW] with a start time, end time, and symptom summary, and a [PIPELINE_EVENTS] list containing timestamps, event types, statuses, and artifact or change identifiers.

Do not use this prompt when the incident is clearly unrelated to CI/CD activity—for example, a pure infrastructure failure like a network partition or a third-party outage with no recent deployments. Do not use it as a substitute for a postmortem process; it provides correlation hypotheses, not a definitive root cause. Always validate the output against your observability data before taking action, especially for high-severity incidents where a rollback or hotfix decision carries significant risk. The next section provides the exact prompt template you can copy and adapt for your environment.

The following prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a DevOps correlation analyst, ingesting structured data about a CI/CD pipeline and an incident to produce a ranked, evidence-backed list of suspect events. Before using this prompt, you must populate the square-bracket placeholders with real data from your pipeline, monitoring, and incident management systems. The prompt enforces a strict output schema, requires evidence for every correlation, and explicitly instructs the model to state when data is missing or inconclusive—preventing confident but unsupported assertions.

textCopy
You are a DevOps correlation analyst. Your task is to correlate CI/CD pipeline events with an active incident window to identify which pipeline events may have contributed to or signaled the incident.

## INCIDENT CONTEXT
- Incident ID: [INCIDENT_ID]
- Incident Start Time: [INCIDENT_START_TIME]
- Incident End Time: [INCIDENT_END_TIME] (or 'ongoing')
- Incident Severity: [INCIDENT_SEVERITY]
- Primary Symptom: [PRIMARY_SYMPTOM]
- Affected Services: [AFFECTED_SERVICES]

## PIPELINE DATA
A JSON array of pipeline events that occurred within a 4-hour window before and during the incident. Each event has the following structure:

[PIPELINE_EVENTS_JSON]

## CONSTRAINTS
- Rank events by likelihood of contribution to the incident, not just by temporal proximity.
- For each ranked event, provide specific evidence from the pipeline data (e.g., test failure names, artifact diff summaries, deployment target).
- If an event's relationship to the incident is unclear, state the uncertainty explicitly and suggest what additional data would resolve it.
- Do not fabricate causal links. If the data is insufficient to connect an event to the incident, place it in an 'Inconclusive' section.
- Consider the following correlation signals:
  - Temporal proximity to incident start.
  - Test regressions that match the incident symptom.
  - Deployment of services listed in AFFECTED_SERVICES.
  - Artifact or configuration changes to incident-related components.
  - Failed or rolled-back deployments.

## OUTPUT SCHEMA
Return a single JSON object with the following structure. Do not include any text outside the JSON object.
{
  "incident_id": "string",
  "correlation_window": "string (human-readable time range analyzed)",
  "total_events_analyzed": "number",
  "ranked_suspect_events": [
    {
      "rank": "number",
      "pipeline_event_id": "string",
      "event_type": "string (e.g., deployment, test_run, artifact_publish, rollback)",
      "correlation_strength": "high | medium | low",
      "evidence": ["string (specific evidence from pipeline data)"],
      "hypothesis": "string (how this event could explain the incident symptom)",
      "confidence": "number (0.0 to 1.0)"
    }
  ],
  "inconclusive_events": [
    {
      "pipeline_event_id": "string",
      "reason": "string (why correlation could not be determined)",
      "missing_data": ["string (what data would help resolve this)"]
    }
  ],
  "overall_assessment": "string (summary of findings and recommended next steps)"
}

To adapt this prompt for your environment, replace the placeholders with live data. The [PIPELINE_EVENTS_JSON] placeholder expects a JSON array of objects, each containing at minimum an id, timestamp, type, status, and details field. You can enrich this with deployment targets, test suite results, artifact SHAs, and configuration diffs. The more structured data you provide, the more precise the correlation will be. If your pipeline data is spread across multiple systems (e.g., Jenkins for CI, ArgoCD for CD, a separate test reporting tool), aggregate and normalize it into the expected JSON structure before calling the prompt. For high-severity incidents where a wrong correlation could misdirect the response team, route the model's output to a human reviewer before acting on the ranked list. Implement a validation step that checks the output JSON against the schema and rejects malformed responses, triggering a retry with a stricter format reminder.

This prompt is designed to be called from an automated incident response bot, a postmortem generation pipeline, or a manual investigation CLI tool. The calling application is responsible for gathering and normalizing the raw data before invoking the model. Pre-process pipeline events from your CI/CD system—such as Jenkins, GitHub Actions, GitLab CI, CircleCI, or Spinnaker—into the JSON schema defined in the Output Contract section. Normalize all timestamps to UTC before calling the prompt to ensure consistent correlation with the incident window. The application should construct the final prompt by injecting the pre-processed pipeline events, the incident window, and any relevant deployment change records into the [INPUT] placeholder.

After the model returns a response, the application must validate the output against the expected JSON schema using a strict validator. If the model returns malformed JSON, implement a retry with exponential backoff (e.g., 1s, 2s, 4s delays) before re-invoking the prompt. If the model returns a correlation with a confidence score below 0.5, suppress that item from the final output and log it separately for offline review by the on-call team. For high-severity incidents, require a human to explicitly confirm any correlation marked as likely_root_cause before it is written into the postmortem document. Always log the full prompt and the raw model response for auditability, storing them alongside the incident record.

Choose a model with strong JSON mode and instruction-following capabilities for this workflow. Avoid models that are prone to hallucinating timestamps or fabricating pipeline event details. The prompt does not require tool use or retrieval-augmented generation (RAG) because all necessary context is injected at call time. The primary failure mode in production is the model proposing a correlation that is chronologically impossible (e.g., a pipeline failure after the incident was already resolved). Mitigate this by adding a post-processing rule that discards any correlation where the pipeline event timestamp falls outside the incident window. Do not pass unvalidated model output directly to downstream systems like ticketing tools or status pages.