Agent Process Diagnostic Reports and Crash Evidence

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Crash evidence lets agents distinguish application exceptions, runtime faults, out-of-memory kills, signal exits, container restarts, and missing log retention.

## Core Explanation

An agent investigating a crash should not rely only on the final error message. The useful evidence is the process exit code, signal, runtime diagnostic report, previous container logs, stack trace, loaded modules, memory limits, restart count, and deployment version.

Diagnostic reports and fault handlers preserve context that ordinary logs may miss. They can show runtime version, thread state, stack frames, resource usage, and process arguments. In container platforms, previous logs and restart metadata are often the only evidence after a container has been replaced.

Agents should treat diagnostic artifacts as sensitive operational data. They should summarize the crash signature, redact secrets, and link the exact artifact or log window used for the conclusion.

## Source-Mapped Facts

- Node.js report documentation describes a diagnostic report that summarizes diagnostic information for a Node.js process. ([source](https://nodejs.org/api/report.html))
- Python faulthandler documentation describes dumping Python tracebacks explicitly on a fault, timeout, or user signal. ([source](https://docs.python.org/3/library/faulthandler.html))
- Kubernetes documentation describes using previous container logs to inspect logs from a crashed container instance. ([source](https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/))

## Further Reading

- [Node.js Diagnostic Report](https://nodejs.org/api/report.html)
- [Python faulthandler](https://docs.python.org/3/library/faulthandler.html)
- [Kubernetes Debug Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/)