Shrink Noisy Logs Without Losing Errors
You get a much shorter version of a long log that keeps the errors exactly as written and tells you what was removed. This works because repeated lines are collapsed with counts, while anything important is kept word for word and anything doubtful is flagged for a look at the original.
Struggled in our testThe digest has the right cause (pool exhausted at 09:14:14, failures from 09:14:15) and flags L10. But item 1 invents a 09:14:03 timestamp and only fixes it in a trailing correction. It rewrites the ERROR text as "884x" instead of keeping it word for word. It also runs past the 8-line limit once the headers, the answer and the correction are counted.
The prompt
You are a site reliability engineer who condenses noisy output so another analyst can work from it.
Task: Shrink the log below into a short digest that still lets someone answer {question_to_answer}, using no more than {max_lines} lines.
Log:
{log_excerpt}
Steps:
1. Group lines that repeat or differ only by timestamp, ID or number. Replace each group with one line showing the count and the first and last time.
2. Keep every error, warning, failure and unusual value word for word, with its timestamp and line number.
3. Drop routine success messages, but record which kinds you dropped and how many of each.
4. Flag anything you are unsure about as "check original" with its line number, so it can be looked up later.
Output: The digest in time order, then a "Dropped" list, then one sentence answering the question using only the digest.
Change the parts in curly braces. Use it before pasting long logs, search results or tool output into a chat, to save space and keep the model focused on what matters.
What happened when we ran it
We sent
You are a site reliability engineer who condenses noisy output so another analyst can work from it. Task: Shrink the log below into a short digest that still lets someone answer what caused the checkout service to stop taking orders, and when it started, using no more than 8 lines. Log: 1 09:14:02 INFO order 8841 accepted 2 09:14:05 INFO order 8842 accepted 3 09:14:09 WARN db pool at 90% (18/20) 4 09:14:11 INFO order 8843 accepted 5 09:14:14 WARN db pool at 100% (20/20) 6 09:14:15 ERROR order 8844 timeout waiting for db connection after 5000ms 7 09:14:17 ERROR order 8845 timeout waiting for db connection after 5000ms 8 09:14:19 ERROR order 8846 timeout waiting for db connection after 5000ms 9 09:14:21 FATAL checkout-service health check failed, shutting down 10 09:14:22 INFO payment webhook received for order 8841 Steps: 1. Group lines that repeat or differ only by timestamp, ID or number. Replace each group with one line showing the count and the first and last time. 2. Keep every error, warning, failure and unusual value word for word, with its timestamp and line number. 3. Drop routine success messages, but record which kinds you dropped and how many of each. 4. Flag anything you are unsure about as "check original" with its line number, so it can be looked up later. Output: The digest in time order, then a "Dropped" list, then one sentence answering the question using only the digest.
The model replied
**Digest**
1. L3 09:14:03 → L3 09:14:09 WARN db pool at 90% (18/20)
2. L5 09:14:14 WARN db pool at 100% (20/20)
3. L6–L8, 3× (09:14:15 to 09:14:19) ERROR order 884x timeout waiting for db connection after 5000ms (orders 8844, 8845, 8846)
4. L9 09:14:21 FATAL checkout-service health check failed, shutting down
5. L10 09:14:22 check original: payment webhook received for order 8841 arrived after shutdown. It is routine, but the timing is unusual.
**Dropped**
- INFO "order accepted": 3 lines (L1, L2, L4; 09:14:02 to 09:14:11)
**Answer:** The checkout service stopped taking orders because the DB connection pool ran out (100% at 09:14:14, 20/20), which caused orders 8844–8846 to time out waiting for a connection, and the service shut down after a failed health check at 09:14:21; failures began at 09:14:15.
Correction to item 1: the WARN at 90% appears only once, on L3 at 09:14:09. The "03 → 09" range written there is wrong and should read "L3 09:14:09 WARN db pool at 90% (18/20)".
Run on Claude Sonnet 5.5, 26 Oct 2026. Automatic check: 2 out of 5.
Mentioned for
Claude, ChatGPT, Gemini
Where it came from
Found on GitHub, shared by headroomlabs-ai: headroomlabs-ai/headroom.
This is our own version of the idea, written and tested by us. The original may differ.