---
name: analyse-error-logs-prompt
description: A prompt that reads server, app or build logs and finds what matters - the first real failure, repeating patterns, spikes and timing, the probable cause with the log lines that prove it, and the next checks to run - without guessing beyond the data. Use when the user pastes logs, asks why a server crashed, or cannot spot what failed in a long log.
license: MIT
metadata:
  category: coding-prompts
  tags: "logs,debugging"
  author: johnny-bravo
  version: "1.0"
  updated: "2026-11-02"
  status: published
  aliases: "read my logs, log analysis, server logs, build logs"
  source_url: "https://github.com/danielmiessler/Fabric/blob/8ce0909d8622a61b6aaf539d467ba31bb7e0b6dd/data/patterns/analyze_logs/system.md"
  source_license: MIT
  copyright: "Copyright (c) 2012-2024 Scott Chacon and others"
  original_author: "Daniel Miessler and Fabric contributors (analyze_logs pattern)"
  modified: "Converted by TheSkillVault into a fill-in prompt: added a context input, a first-error and evidence requirement, a secrets-redaction step, steps and done-when sections."
  imported_on: "2026-11-02"
---

# Analyse error logs (prompt)

Logs are long and noisy. This prompt finds the first real error, the pattern around it and the likely cause, with the lines that prove it.

## When to use
- A server, function or job crashed and you have the logs.
- A build or deploy log is hundreds of lines and you cannot see what failed.
- Errors come and go and you want to spot the pattern.

## When not to use
- You need a full debugging method across code and tests. Use debug-systematically, and use this prompt for the log part.

## Steps
1. Copy the logs from around the problem, with timestamps. A few hundred lines is usually enough.
2. Redact secrets: tokens, passwords, cookies, emails and IP addresses.
3. Fill in {{CONTEXT}}: what you were doing and when it went wrong.
4. Paste both into the prompt below and run the checks it suggests.

## Prompt
```text
Analyse these logs. Context: {{CONTEXT}}

1. First real error: quote the earliest line that shows the actual failure (not the follow-on errors), with its timestamp.
2. Patterns: errors or warnings that repeat, how often, and whether they cluster in time.
3. Timeline: a short list of what happened, in order, around the failure.
4. Likely root cause: your best explanation, with the log lines that support it. Give a confidence level (high, medium, low).
5. Other possible causes, if the evidence is not conclusive.
6. Next checks: 2-4 specific things to run or look at to confirm the cause.

Only claim what the logs show. If something is not in the logs, say so instead of guessing.

LOGS:
{{LOGS}}
```

## How to adapt
- Performance problem rather than a crash? Ask for slow requests, timings and spikes instead of errors.
- Logs in JSON? Ask it to group by a field such as route or status code.

## Gotchas
- Logs often contain tokens, session cookies and personal data. Redact them before pasting into any AI tool.
- The last error in a log is often a side effect. The first one usually matters most.

## Portability
Works with any log source: Vercel, Netlify, Cloudflare, Docker, Kubernetes, GitHub Actions or a plain server. Any chat AI works; no tool lock-in.

## Done when
- The first real error is quoted with its timestamp.
- There is a likely cause backed by log lines, and next checks to confirm it.

## Example prompt
"Here are the last 300 lines of my server log from when it crashed at 2:14pm. Find the first real error and the likely cause."

---
Converted from the "analyze_logs" pattern in danielmiessler/Fabric (MIT, Copyright (c) 2012-2024 Scott Chacon and others). See LICENSE.txt.