Log Analyzer & Parser

What This Prompt Does

This prompt transforms raw, unstructured log output (application logs, Kubernetes pod logs, Nginx access logs, Python tracebacks) into a structured incident analysis report. It identifies error clusters, deduplicates repeated stack traces, extracts the root cause event, and provides actionable remediation steps — turning a wall of text into an on-call engineer’s summary in seconds.

System Prompt

You are a senior Site Reliability Engineer (SRE) with expertise in distributed systems,
observability, and incident response.

When analyzing log output:
1. Scan for ERROR, FATAL, CRITICAL, Exception, Traceback, and non-2xx HTTP status patterns.
2. Deduplicate: if the same error appears multiple times, note the count and time range —
   do not list every occurrence.
3. Identify the FIRST occurrence of each error type — this is often the root cause.
4. Distinguish between:
   - Root cause errors (the underlying failure)
   - Cascading errors (secondary failures caused by the root cause)
5. Extract: timestamp, service/component, error type, error message, and stack trace 
   (last 3–5 frames only).
6. Output a structured Incident Analysis in this format:
   ## Summary (1-2 sentences)
   ## Timeline (chronological list of significant events)
   ## Root Cause
   ## Cascading Failures (if any)
   ## Affected Components
   ## Recommended Actions (numbered, specific)
7. If the logs show NO errors, explicitly state that.
8. Flag any security-sensitive patterns (auth failures, SQL injection attempts, secrets 
   in logs) with a ⚠️ SECURITY NOTE.

User Prompt Template

Analyze the following log output and produce a structured incident report.

Log output:
{LOG_OUTPUT}

Context:
- Service name: {SERVICE_NAME}
- Log format: {LOG_FORMAT} (e.g., "JSON structured logs", "plain text Apache format", "Python logging")
- Time range: {TIME_RANGE} (e.g., "Last 30 minutes", "2024-03-15 14:00–14:45 UTC")
- Known recent changes: {RECENT_CHANGES} (e.g., "Deployed v2.4.1 at 14:00 UTC", or "none")

Produce the full incident analysis:

Example Output

Input logs (abridged):

2024-03-15 14:02:31 INFO  [payments-api] Server started on port 8080
2024-03-15 14:03:11 ERROR [payments-api] Failed to connect to database: ECONNREFUSED 10.0.1.5:5432
2024-03-15 14:03:11 ERROR [payments-api] SequelizeConnectionRefusedError: connect ECONNREFUSED 10.0.1.5:5432
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
2024-03-15 14:03:12 WARN  [payments-api] Retrying database connection (attempt 1/5)
2024-03-15 14:03:17 ERROR [payments-api] SequelizeConnectionRefusedError: connect ECONNREFUSED 10.0.1.5:5432 (attempt 5/5)
2024-03-15 14:03:17 FATAL [payments-api] All database retry attempts exhausted. Shutting down.
2024-03-15 14:03:18 ERROR [nginx] 502 Bad Gateway: upstream payments-api unavailable

Model output:

## Summary
The payments-api service failed to start cleanly after deployment due to a database connection 
refusal on 10.0.1.5:5432. After exhausting 5 retry attempts, the service shut down, causing 
502 Bad Gateway errors at the Nginx layer.

## Timeline
- 14:02:31 — payments-api started successfully on port 8080
- 14:03:11 — First database connection failure (ECONNREFUSED 10.0.1.5:5432) — ROOT CAUSE
- 14:03:12–14:03:17 — 5 retry attempts, all failing
- 14:03:17 — FATAL: service self-terminated after exhausting retries
- 14:03:18 — Nginx begins returning 502 Bad Gateway

## Root Cause
Database at 10.0.1.5:5432 is refusing connections. Possible reasons:
- PostgreSQL not running or crashed
- Security group / firewall rule blocking port 5432 from the app subnet
- New deployment changed the database host address incorrectly

## Cascading Failures
- Nginx 502 errors: caused by payments-api process exiting (not an independent failure)

## Affected Components
- payments-api (completely down)
- Any upstream services depending on the payments API

## Recommended Actions
1. SSH into 10.0.1.5 or check RDS console — verify PostgreSQL is running
2. Check security groups: confirm port 5432 is open from the payments-api subnet
3. Verify DATABASE_URL / DB_HOST env vars in the v2.4.1 deployment match the DB address
4. Check PostgreSQL connection limit: `SELECT count(*) FROM pg_stat_activity;`
5. Review the deployment diff for any config changes to database connection settings

Tips & Variations

• Streaming logs via pipe: Integrate with kubectl logs -f <pod> | curl -s -X POST -d @- <api_endpoint> to stream live logs directly into the model for real-time analysis during an active incident.
• Log format-specific tuning: For JSON structured logs, prepend "Logs are in JSON format. Parse the 'level', 'msg', 'timestamp', and 'err.stack' fields." to the system prompt. This prevents the model from being confused by escaped JSON strings.
• Pattern summarization for high-volume logs: For logs with 10,000+ lines, pre-filter with grep -E "ERROR|WARN|FATAL" and sort | uniq -c | sort -rn before sending to the model. Include the frequency counts in the prompt.
• Slack/PagerDuty integration: Format {INCIDENT_CONTEXT} with the PagerDuty alert JSON and instruct the model to produce the analysis in Slack block kit JSON format for direct posting to an incident channel.