What Is Crash Recovery?

How Crash Recovery Works

What Determines Recovery Speed

1. The Manager's Own Runtime

2. Process Spawn Time

3. Health Check Configuration

What Happens If an App Keeps Crashing?

Crash Recovery vs. High Availability

Measuring Crash Recovery in Your Setup

Crash Recovery in Oxmgr Your production app crashes. A bug slips through, memory spikes, a network dependency times out and throws an unhandled exception — it doesn't matter why. What matters is what happens next. Crash recovery is the automatic process of detecting that an application has died and restarting it as fast as possible, before your users have time to notice. Without crash recovery, a process that crashes stays dead until a human intervenes. With it, the same crash can be invisible — the process restarts in milliseconds and keeps serving traffic. Crash recovery is one of the core reasons you need a process manager in production — without one, there's nothing watching your app to trigger a restart. Every operating system gives processes a way to signal their exit. When a process terminates — whether it crashes, runs out of memory, or is killed — it emits an exit event with a status code. A process manager listens for these events: The critical variable is how long this takes. The gap between the exit event and the new process serving traffic is your downtime window. Three factors control how fast a process manager can recover from a crash: A process manager written in a scripting language (JavaScript, Python, Ruby) has to do real work to respond to an exit event — the VM needs to be scheduled, the garbage collector might pause, the event loop might be busy. A compiled binary (Rust, Go, C) responds in microseconds. There's no VM, no GC, no interpreter. The exit handler fires and the spawn call happens immediately. This is the biggest factor. PM2 (Node.js daemon) recovers in ~400ms. Oxmgr (Rust binary) recovers in ~11ms. Spawning a new process takes time regardless of the manager. For a Node.js app: The process manager can't control how fast your app starts. But it can start the spawn immediately after detecting the crash, rather than waiting for polling intervals. After spawning, the manager needs to know when the process is ready. Two approaches: Port listening — wait until the process binds to its port. Simple, but doesn't guarantee the app is actually serving valid responses. HTTP health check — poll an endpoint until it returns 200. Slower to confirm readiness, but more accurate. For crash recovery, the key is not waiting longer than necessary. If your health check polls every 30 seconds but a crash recovers in 50ms, you're waiting 30 seconds to confirm what already happened. Automatic restart can create a "crash loop" — the app restarts, crashes immediately, restarts again, endlessly. This is worse than staying down in some ways: it makes logs unreadable and consumes CPU spinning up processes. Most process managers handle this with restart limits and backoff: Exponential backoff is more sophisticated — the delay doubles each time: This gives transient issues (network blips, temporary resource exhaustion) time to resolve while preventing runaway loops. These are related but different concepts: Crash recovery handles the period after a single process crashes — the goal is to minimize downtime for that process. High availability uses redundancy to eliminate downtime entirely — run 2+ instances so when one crashes, others continue serving traffic while the crashed one recovers. With 3 instances and 11ms crash recovery, a user hitting the crashed instance during that window is the only exposure. In practice, load balancers have already stopped routing to the crashed process within a similar timeframe. You can test your crash recovery speed manually: For PM2 users, the same test will show you real-world recovery times rather than theoretical numbers. Oxmgr is built around the assumption that crash recovery should be invisible to users. Key settings: With this config, a crash on one instance triggers an immediate restart. The other instance handles traffic during the ~50ms window (11ms manager + ~40ms Node.js startup for a simple app). See the docs for health check configuration and resource limit triggers. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse