Crash diagnostics
Crash reports with the likely cause; your own AI assistant reads the details
How it works, with exact details
When an app crashes, Percher records a crash report with the end of the log, explains the likely cause and emails you. The report is on the app's Health page.
Percher recognises common causes with fixed rules: running out of memory, a missing package or file, a syntax error, a port the app cannot listen on, a missing environment variable, an unreachable database, an uncaught async error, and outbound requests that bypass Percher's network proxy. Anything else is reported with its exit code and the log tail.
Use Percher Doctor
Doctor checks app health and reports likely causes with a suggested next step. It does not edit your code or redeploy the app; you or your assistant apply any fix separately.
From a terminal, replace my-app with your app's name:
Omit --mode runtime for general health checks. Run bunx percher login first if you are not signed in.
Percher does not send crash logs to an external AI provider. With the local MCP server, ask your own assistant: “Run percher doctor for my Percher app "my-app" in runtime mode and explain why it crashed.” It calls percher_doctor with mode="runtime" and gets the crash report and log tail.
The hosted connector can inspect a failed deploy's build log with percher_deploys_inspect. It cannot read runtime logs or crash reports; open the app's Health and Logs tabs in the dashboard.
The watchdog checks for stopped containers every five seconds by default. Reports older than 24 hours on apps that have recovered are left out of doctor's result.