Structured Log Entry Prompt Template for SRE Incident Reports

This prompt is designed for Site Reliability Engineers (SREs) and on-call responders who need to convert messy, natural-language incident narratives into a single, machine-parseable JSON log entry. The primary job-to-be-done is normalizing human-written incident updates, chat transcripts, or alert notes into a consistent schema that can be directly ingested by observability platforms like Splunk, Elasticsearch, or Datadog. It is ideal for users who are building an AI-assisted incident management harness and need every log entry to contain a valid severity level, a UTC timestamp, a trace ID, and an affected service name without manual field extraction.

Use this prompt when you have a stream of unstructured text from an active incident and you need a structured record for automated dashboarding, alert correlation, or postmortem timeline reconstruction. It is specifically tuned for high-pressure operational contexts where the model must not hallucinate severity levels or invent timestamps. The prompt template requires a [CONTEXT] block containing the raw incident notes and a [CONSTRAINTS] block where you define your allowed severity enum and timestamp format. Do not use this prompt for generating long-form postmortem documents, analyzing multi-incident trends, or extracting data from pre-formatted log lines; it is strictly for normalizing a single, human-generated incident update into a single JSON object.

Before putting this into production, ensure your application layer validates the output against a JSON Schema that enforces the timestamp format (e.g., RFC 3339) and the severity enum you provided. The prompt is a component, not a complete solution. You must wire it into a harness that handles retries on validation failure, logs the raw input and parsed output for auditability, and escalates to a human on-call if the model consistently fails to produce a valid record. If the incident involves regulated data or safety-critical infrastructure, always require human review of the structured log before it is written to your system of record.

This template is the core instruction set for producing a structured incident log entry. It is designed to be copied directly into your prompt management system, IDE, or orchestration code. The prompt uses square-bracket placeholders for all dynamic inputs, ensuring you can swap in incident context, severity taxonomies, and output schemas without rewriting the core logic. The goal is a single, valid JSON object that can be ingested by your observability platform or incident management tool without post-processing.

textCopy
System: You are an SRE incident logging assistant. Your only job is to produce a single, valid JSON object representing a structured incident log entry. Do not include any explanatory text, markdown fences, or conversational filler outside the JSON object.

User:
Generate a structured incident log entry using the following inputs.

Incident Context:
[INCIDENT_CONTEXT]

Severity Taxonomy:
[SEVERITY_TAXONOMY]

Output Schema:
[OUTPUT_SCHEMA]

Constraints:
[CONSTRAINTS]

Examples:
[EXAMPLES]

To adapt this template, replace each placeholder with concrete values. [INCIDENT_CONTEXT] should contain the raw alert, runbook step, or user report. [SEVERITY_TAXONOMY] must define the valid severity levels (e.g., SEV0, SEV1, SEV2) to prevent the model from inventing its own. [OUTPUT_SCHEMA] should be a JSON Schema or a detailed field specification including required fields like timestamp, trace_id, and affected_service. [CONSTRAINTS] is where you enforce rules like RFC 3339 timestamps or UUID4 trace IDs. [EXAMPLES] should provide one or two few-shot demonstrations of correct output for different severity levels. After generating the output, always validate the JSON structure, timestamp format, and severity level against your schema before ingestion. For high-severity incidents, route the output for human review before paging on-call engineers.

This prompt is designed to be called by an SRE automation layer, not directly by a human during an active incident. The typical integration point is a webhook receiver from your monitoring stack (PagerDuty, Opsgenie, Grafana OnCall) or a chat-ops command in Slack/Teams. When an incident is declared, the application should assemble the [INCIDENT_DETAILS] placeholder from structured alert payload fields—alert_name, firing_timestamp, metric_labels, runbook_url—and inject them into the prompt template. Do not pass raw, unparsed alert JSON; extract and normalize the fields first to prevent prompt injection via alert labels or free-text descriptions.

The implementation harness must enforce a strict validation loop. After the model returns the JSON log entry, validate it against a JSON Schema that checks: timestamp is ISO 8601 with timezone offset, severity is one of INFO, WARNING, ERROR, CRITICAL, trace_id matches a UUID v4 regex, and affected_services is a non-empty array of strings. If validation fails, use a repair retry pattern: append the validation errors to the original prompt as a [REPAIR_CONTEXT] block and re-invoke the model once. If the second attempt fails, log the raw output and escalate to the on-call engineer via the incident channel—do not retry indefinitely. For model choice, a fast model like claude-3-haiku or gpt-4o-mini is sufficient for this structured extraction task; reserve larger models for the repair step if needed.

Log every step of this pipeline—prompt version, model ID, input hash, output, validation result, and retry count—as structured application logs. This audit trail is critical for debugging prompt drift and proving to auditors that AI-generated incident records are traceable. Wire the validated JSON output directly into your incident management database (e.g., a incident_logs table) and your observability platform as a custom event. Finally, ensure a human reviews any log entry with severity: CRITICAL before it triggers downstream automation like status page updates or customer notifications; the prompt is a drafting tool, not an autonomous operator for high-severity communications.