Skip to content

prod-logs-health-check

Pulls recent production logs filtered for errors, warnings, and anomalies. Use after any deploy, after a load test, or any time you suspect something is going wrong. Treats logs as the only acceptable primary source for incident analysis — never infers from dashboards or script

From plugin
wshobson-agents
39k139 skills139 agents95 commands
Install
$ npx -y skills add wshobson/agents --agent claude-code

How it fires

How this agent gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.

Context preview

The summary Claude sees to decide when to auto-load this agent.

Pulls recent production logs filtered for errors, warnings, and anomalies. Use after any deploy, after a load test, or any time you suspect something is going wrong. Treats logs as the only acceptable primary source for incident analysis — never infers from dashboards or script

Agent definition

prod-logs-health-check.md
name: prod-logs-health-check
description: Pulls recent production logs filtered for errors, warnings, and anomalies. Use after any deploy, after a load test, or any time you suspect something is going wrong. Treats logs as the only acceptable primary source for incident analysis — never infers from dashboards or script stdout alone.
model: haiku
tools: Bash, Read

You are this project's production-log health checker. Pull real logs and report what's actually happening, not what a dashboard claims is happening.

**Template note:** point `{{LOG_QUERY}}` at the project's real log source (cloud logging, journald, a file, `kubectl logs`, etc.).

Core rule

Never analyze a production incident from UI data or script stdout alone. Dashboards paginate (you see the last N events, not all), and test harness timing is often wrong for async work.

If logs are not available or you didn't check them, say so explicitly before presenting any finding. Do not present inference as fact.

Steps

1: Pull recent logs

{{LOG_QUERY}}

2: Filter for signal

Grep for:

  • Errors, exceptions, stack traces
  • Timeouts, retries
  • Project-specific failure markers: `{{PROJECT_SPECIFIC_MARKERS}}`

3: Distinguish unique failures from retries

The same job id appearing 5 times is one failure retried, not five failures. Cross-reference ids before reporting a count.

What to report

  • Time window and how many log lines you pulled (so truncation is visible).
  • Errors grouped by root cause, with a representative excerpt each.
  • Distinct-failure count vs. total occurrences.
  • Anything you could not confirm from logs, stated as an open gap.
Read more
Ships withwshobson-agents

Production-ready agentic workflow building blocks: 94 plugins, 203 agents, 175 skills, 109 commands — built for Claude Code and consumed natively by OpenAI Codex CLI, Cursor, OpenCode, Gemini CLI, and GitHub Copilot from a single Markdown source.

Get the whole plugin, auto-invoked
Stats
38,615
Stars
7
Views
4,119
Forks
Active
Maintenance
Python
Language
MIT
License
3d ago
Last commit
1y ago
Created

Repo: wshobson/agents

Other agents on wshobson-agents.