Application Log Error Stack Trace Extraction Prompt Template

This prompt is designed for SRE and platform engineers who need to convert raw, unstructured application logs into structured error records for alerting, deduplication, and incident response. The ideal user is an engineer building or maintaining an internal observability pipeline who receives multi-line exception dumps, stack traces, and surrounding request context that must be normalized before automated analysis can occur. The core job-to-be-done is transforming a noisy, multi-line log entry into a single, predictable JSON object that can be ingested by monitoring systems like Datadog, Sentry, or a custom incident management platform without manual parsing.

Use this prompt when your logs contain exceptions with stack frames that include file paths and line numbers, and when those exceptions are accompanied by contextual request data such as HTTP method, URL, user ID, or trace ID. The prompt is specifically tuned to correlate multi-line stack traces that may be interleaved with other log lines, deduplicate repeated errors within the same input window, and produce a consistent output schema even when some fields are missing. Do not use this prompt for simple single-line log parsing, for logs that lack stack trace structure entirely, or for binary or highly structured log formats like syslog RFC 5424 messages that already have a defined schema. It is also not suitable for logs where the primary goal is metric extraction rather than error record normalization.

Before using this prompt, ensure your log input has been pre-segmented into coherent error windows—individual exceptions or crash reports rather than raw streaming log tails. The prompt assumes it receives a bounded text block representing one or more related errors. If you feed it an unbounded stream of mixed log levels, it will struggle to identify error boundaries and may produce incomplete or overlapping records. For high-severity incidents where the error structure directly triggers paging, always pair this prompt's output with a validation layer that checks for required fields like error_type and stack_frames before the record enters your alerting pipeline. When in doubt, route records with missing critical fields or low extraction confidence to a human review queue rather than silently dropping them.

This prompt template is designed to be copied directly into your AI harness, test suite, or orchestration layer. It expects raw, multi-line application log text as input and produces a structured JSON array of error records. Each record includes the error type, message, stack frames with file and line references, and any contextual request data found in the log. The template uses square-bracket placeholders that you must replace with your specific configuration before use.

textCopy
You are an SRE log analysis assistant. Your task is to extract structured error records from raw application logs.

## INPUT
Analyze the following raw application log text:

[RAW_LOG_TEXT]

## OUTPUT SCHEMA
Return a valid JSON object with a single key "errors" containing an array of error objects. Each error object must follow this exact schema:
{
  "error_type": "string (e.g., NullPointerException, TimeoutError, DatabaseConnectionError)",
  "error_message": "string (the exact error message, truncated to 500 characters if longer)",
  "stack_frames": [
    {
      "file": "string (file path from the stack trace, or null if unavailable)",
      "line": "integer (line number, or null if unavailable)",
      "function": "string (function or method name, or null if unavailable)"
    }
  ],
  "request_context": {
    "request_id": "string (extracted request or trace ID, or null)",
    "url": "string (request URL or endpoint, or null)",
    "method": "string (HTTP method, or null)",
    "user_id": "string (user identifier, or null)",
    "timestamp": "string (ISO 8601 timestamp of the error, or null)"
  },
  "deduplication_key": "string (a hashable string composed of error_type + first stack frame file + first stack frame function, used to group identical errors)"
}

## CONSTRAINTS
- Group multi-line stack traces into a single error record. A stack trace ends when a new log line starts with a different timestamp or log level, or when the indentation returns to the left margin.
- If the same error type and stack trace appear multiple times, create a single record and set a field "occurrence_count" to the number of repetitions. Do not create duplicate records.
- If a stack frame lacks file or line information, set those fields to null. Do not hallucinate values.
- If no request context is found in the log lines surrounding the error, set all request_context fields to null.
- If the log contains no errors, return {"errors": []}.
- Do not include any commentary, markdown fences, or additional text outside the JSON object.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your specific configuration. [RAW_LOG_TEXT] should be populated with the actual log content at runtime. [FEW_SHOT_EXAMPLES] should contain 2-3 example input-output pairs that demonstrate your expected behavior, especially for multi-line stack trace grouping and deduplication. [RISK_LEVEL] should be set to "low" (fully automated), "medium" (automated with sampling review), or "high" (human review required for all outputs) based on your downstream use case. For high-risk environments such as security incident response or financial system debugging, always require human review and ensure the output is logged for auditability. Before deploying, validate the output against your schema using a JSON Schema validator and run a regression suite of known log samples to catch extraction drift.

Integrating this prompt into an application requires treating it as a deterministic extraction step inside a broader log processing pipeline, not a standalone chatbot. The prompt expects raw log chunks that may contain multi-line stack traces, so the application layer must first segment logs into coherent error blocks before calling the model. A common pattern is to use a regex or log parser to identify error boundaries—such as lines starting with ERROR, FATAL, or Exception—and group subsequent indented or continuation lines into a single input for the model. This pre-segmentation prevents the model from receiving partial stack traces and reduces token waste on irrelevant log lines.

After calling the model, the application must validate the structured output against the expected schema before ingestion. Check that error_type is a non-empty string, message is present, and stack_frames is an array where each frame contains file, line, and function fields. Reject or flag records where the model returns null for required fields or where stack_frames is empty despite a stack trace being present in the input. For deduplication, compute a fingerprint from the normalized error type and the top frame of the stack trace, then check against a cache or database of recently seen errors. This prevents the same recurring error from flooding downstream alerting systems. Use a short TTL cache—such as 5 minutes—to suppress duplicates while still capturing error frequency for metrics.

Model choice matters for this workflow. Use a model with strong JSON mode and instruction-following capabilities, such as GPT-4o, Claude 3.5 Sonnet, or a fine-tuned open-weight model if latency and cost require local inference. Set temperature to 0 or a very low value to maximize deterministic extraction. Enable structured output mode if the provider supports it, passing the full JSON schema rather than relying on prompt-level format instructions alone. For high-throughput environments, batch multiple error blocks into a single request where the model returns an array of extraction results, but keep batch sizes small enough that a single failure doesn't require reprocessing a large window. Log every extraction attempt—including raw input, model output, validation result, and fingerprint—so that extraction quality can be audited and prompt regressions detected.

When wiring this into an incident response or alerting pipeline, add a human review gate for errors classified as severity: critical or where the model's confidence in the root cause category is below a defined threshold. Route these to an on-call engineer or a review queue rather than auto-creating tickets. For errors that match known benign patterns—such as client-side timeouts or expected maintenance windows—suppress alerting entirely based on a configurable allowlist. The extraction prompt itself should not make suppression decisions; keep that logic in the application layer where rules can be updated without changing the prompt. Finally, monitor extraction throughput, validation failure rate, and deduplication hit rate as key health metrics for the pipeline.