diagnose-crash

Diagnoses crashes and OOM kills by analyzing journald boots, DiagnosticReports, and Windows Event Logs.

2|Updated Jun 14, 2026
One-click install
npx skills add https://github.com/odysseyalive/claude-watchman --skill diagnose-crash-odysseyalive
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: diagnose-crash
Source: https://github.com/odysseyalive/claude-watchman/tree/main/skills/logic/diagnose-crash
Command: npx skills add https://github.com/odysseyalive/claude-watchman --skill diagnose-crash-odysseyalive

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a server or workstation crashes, reboots unexpectedly, or kills processes due to memory pressure, the evidence is scattered across prior boot logs, diagnostic reports, and event logs. This Skill performs the postmortem for you: it walks the logs across boots, identifies the victim process and the memory hog, and records a deduplicated finding with a concrete remediation suggestion. ## Core Features & Use Cases - Cross-boot crash analysis on Linux: Walks journalctl across boots to find OOM kills and services exiting with code 137 (SIGKILL from the OOM killer). - macOS jetsam and crash forensics: Reads DiagnosticReports (JetsamEvent, EXC_RESOURCE) and queries the Unified Log for memory-kill events. - Windows Event Log mapping: Translates Kernel-Power 41, BugCheck 1001, and WER application crash events into crash evidence. - Use Case: After an unexpected reboot of a production Linux server, run this Skill to discover that mysqld was OOM-killed, and receive a journaled, high-severity finding suggesting an OOMScoreAdjust or cgroup MemoryMax fix. ## Quick Start Ask the AI to run the diagnose-crash skill to investigate why the machine rebooted or which process was killed by memory pressure.

Frequently Asked Questions about diagnose-crash

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find out why my Linux server rebooted unexpectedly?▼

Walk journalctl across boots with journalctl --list-boots and search prior boots for kernel OOM messages and services exiting with code 137. The evidence of a crash typically lives in the boot before the current one, which this Skill checks automatically.

How to diagnose OOM killer events on Linux?▼

Search the kernel log with journalctl -k -g 'Out of memory|Killed process|oom' for each boot. The Skill extracts the killed victim process and the memory hog, then journals a high-severity finding suggesting OOMScoreAdjust or cgroup MemoryMax remediation.

Does this crash analysis work on macOS and Windows?▼

Yes. On macOS it reads JetsamEvent reports from DiagnosticReports and queries the Unified Log for jetsam events. On Windows it maps Event Log IDs 41, 6008, 1001, and application crash events 1000/1001 to crash evidence.

Can this tool automatically fix OOM or crash problems?▼

No. The Skill is strictly read-only: it diagnoses the cause and journals a remediation suggestion, but applying memory limits or changing service configuration is review-tier work left to the operator-run fixer with explicit approval.

Why does crash diagnosis require logs to persist across boots?▼

A reboot usually follows the failure, so the causal evidence lives in the previous boot's journal. If journald is not configured for persistent storage, that evidence is lost, which is why the Skill depends on the check-log-retention finding.