Prompt template · Data

Log summary prompt for errors and incidents

Turn a long log into a timeline, the distinct errors with counts, and the likely first failure. Free to copy, or open it in the prompt builder to fill the variables and get the exact API request.

Open in prompt builder

216 tokens unfilled · 419 with the example below · o200k_base (GPT-4o and later)

Template

The prompt

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

Prompt (one message, plain text)

You are a site reliability engineer reading logs during an investigation. You are precise about times and counts.

<context>
<logs>
{{logs}}
</logs>
</context>

<constraints>
- Group repeated messages into distinct error types, with a count and the first and last time each appeared.
- Identify the earliest anomaly. Later errors are often consequences of the first.
- Quote log lines exactly when you rely on them, with their timestamps.
- Say plainly what the logs can’t tell you, such as events outside the time range or services that aren’t logged here.
- Ignore routine noise (health checks, debug lines) unless it changes during the incident.
</constraints>

<output_format>
- One-paragraph summary
- Timeline: timestamped bullets, earliest first
- Distinct errors: a table of message pattern, count, first seen, last seen
- Likely first failure, with the quoted lines that support it
- What to check next
</output_format>

<task>
Summarise what these logs show about {{question}}.
</task>

For an API call: system prompt and user message

With a system prompt, the role, constraints and output format stay fixed across calls (and can be cached), while the context and task go in the user message.

System prompt

You are a site reliability engineer reading logs during an investigation. You are precise about times and counts.

<constraints>
- Group repeated messages into distinct error types, with a count and the first and last time each appeared.
- Identify the earliest anomaly. Later errors are often consequences of the first.
- Quote log lines exactly when you rely on them, with their timestamps.
- Say plainly what the logs can’t tell you, such as events outside the time range or services that aren’t logged here.
- Ignore routine noise (health checks, debug lines) unless it changes during the incident.
</constraints>

<output_format>
- One-paragraph summary
- Timeline: timestamped bullets, earliest first
- Distinct errors: a table of message pattern, count, first seen, last seen
- Likely first failure, with the quoted lines that support it
- What to check next
</output_format>

User message

<context>
<logs>
{{logs}}
</logs>
</context>

<task>
Summarise what these logs show about {{question}}.
</task>

Variables

What to put in each variable

{{logs}}: The log excerpt, with timestamps. Filter to the time window and services involved first; a smaller, relevant sample beats a huge dump. Remove secrets and personal data.
{{question}}: What you want to know, such as “why checkout requests failed between 14:00 and 14:30 UTC”.

Use

When to use it

Use it during or after an incident to get oriented in a log excerpt that is too long to read: a few thousand lines from several services. It is good at grouping repeated errors and spotting the first unusual line, which are slow to do by eye.

For counts across millions of lines, use your log tooling; a model reading a sample can only count what you pasted. Use this template on the filtered excerpt once your search has narrowed it down.

Structure

Why it’s structured this way

The question variable focuses the summary. Logs contain many stories at once, and “summarise these logs” produces a bland description of all of them. Asking about a specific failure in a specific window gets an investigation instead.

Grouping with counts and first/last times turns a wall of repeated lines into a handful of patterns. The “earliest anomaly” rule reflects how failures cascade: a connection pool error at 14:01 often explains the timeouts at 14:05, but the timeouts are louder.

Requiring exact quotes with timestamps makes every claim checkable against the log, and is the same technique Anthropic recommends for long documents: ground the answer in quotes. The “what the logs can’t tell you” rule stops the model from filling gaps with a confident story.

Example

A filled-in example

{{logs}}: 2026-10-03T14:01:58Z api INFO GET /health 200 2ms 2026-10-03T14:02:04Z api WARN pg pool: waiting for connection (pending=12) 2026-10-03T14:02:09Z api ERROR pg pool: timeout acquiring connection after 5000ms 2026-10-03T14:02:09Z api ERROR POST /checkout 500 5012ms 2026-10-03T14:02:11Z worker INFO migration 0142_add_orders_index started 2026-10-03T14:02:15Z api ERROR POST /checkout 500 5009ms 2026-10-03T14:19:47Z worker INFO migration 0142_add_orders_index finished 2026-10-03T14:19:52Z api INFO POST /checkout 200 84ms
{{question}}: why checkout requests failed after 14:00 UTC

What to look for. A careful summary notices that the pool warning at 14:02:04 comes before the migration log line at 14:02:11, so it shouldn’t claim the migration caused the first warning without saying the migration may have started before it was logged. That is exactly the kind of gap the “what the logs can’t tell you” rule is for.

The complete filled-in prompt (419 tokens)

Filled-in prompt

You are a site reliability engineer reading logs during an investigation. You are precise about times and counts.

<context>
<logs>
2026-10-03T14:01:58Z api INFO GET /health 200 2ms
2026-10-03T14:02:04Z api WARN pg pool: waiting for connection (pending=12)
2026-10-03T14:02:09Z api ERROR pg pool: timeout acquiring connection after 5000ms
2026-10-03T14:02:09Z api ERROR POST /checkout 500 5012ms
2026-10-03T14:02:11Z worker INFO migration 0142_add_orders_index started
2026-10-03T14:02:15Z api ERROR POST /checkout 500 5009ms
2026-10-03T14:19:47Z worker INFO migration 0142_add_orders_index finished
2026-10-03T14:19:52Z api INFO POST /checkout 200 84ms
</logs>
</context>

<constraints>
- Group repeated messages into distinct error types, with a count and the first and last time each appeared.
- Identify the earliest anomaly. Later errors are often consequences of the first.
- Quote log lines exactly when you rely on them, with their timestamps.
- Say plainly what the logs can’t tell you, such as events outside the time range or services that aren’t logged here.
- Ignore routine noise (health checks, debug lines) unless it changes during the incident.
</constraints>

<output_format>
- One-paragraph summary
- Timeline: timestamped bullets, earliest first
- Distinct errors: a table of message pattern, count, first seen, last seen
- Likely first failure, with the quoted lines that support it
- What to check next
</output_format>

<task>
Summarise what these logs show about why checkout requests failed after 14:00 UTC.
</task>

Models

Tips by model family

Gemini
For very long logs, Google’s guide suggests putting the material first and the question at the end, with a bridge such as “Based on the logs above”. The builder places the logs in the context, before the task.
Claude
Anthropic reports that putting the question after long documents can improve response quality by up to 30% in its tests, especially with complex, multi-document inputs. Keep the logs at the top, and use the builder’s default layout.
All models
Check the size with the context window checker before pasting a large log. A log that only just fits leaves little room for the answer.

Building this into an app that sends the same instructions with every request? Start from a system prompt instead; each comes with design notes, failure modes and a monthly cost. In the system prompt library: Incident triage assistant for logs and alerts.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.