Skip to content
BuildThenTestedSee packages
MediumReliability

One process, one machine, nothing restarts it

An unhandled error, an out-of-memory crash or a host reboot takes the whole app offline, and it stays offline until a person logs in and starts it again, often after customers have already emailed. Whether the app keeps working when something fails. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

# start command on the VM
node server.js

# or, in a container
docker run -d -p 3000:3000 myapp
# --restart not set: the default is "no"
An app that runs as one process on one machine, started by hand or by a container command with no restart policy, so a crash keeps it down until someone notices.

What happens

An unhandled error, an out-of-memory crash or a host reboot takes the whole app offline, and it stays offline until a person logs in and starts it again, often after customers have already emailed.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

  1. Find out where the app runs. In Replit, open the Publishing pane and read the deployment type. On a server or container host, open the provider's dashboard and look for "restart policy", "health check" or "process manager".
  2. At a quiet time, stop the app process from the dashboard (or ask whoever set it up to do so), then open the app URL a minute later.
  3. Check the deployment type again: an Autoscale or serverless deployment starts instances for you; a Reserved VM or plain server relies on what is inside it.

Bad result: after the process stops, the site stays down until someone restarts it by hand, or the dashboard shows a single machine with no restart policy and no health check.

What we check

With your permission we crash the process on purpose (an unhandled rejection and a memory spike) and time how long the app takes to answer again, then check what is watching it. The report states the recovery time and whether anyone would have been alerted.

Fix direction

Run the app under something that restarts it: a process manager such as pm2 or systemd, a container with --restart unless-stopped, or a platform deployment type that manages instances for you. Add an uptime check that alerts you, and handle unhandledRejection so a single bad request does not take the process down.

Mechanism documented in: Replit Docs: Reserved VM Deployments (verified 2026-09-21); Docker Docs: Start containers automatically (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Full audit ($1,900, 5 business days)

Both include a re-check after your fixes.

Compare packages

Related patterns

  • Background jobs that fail silentlyReliability

    Emails, invoices, syncs or clean-ups quietly stop for some or all users, and you find out weeks later from a customer rather than from the system.

    Medium
  • Errors swallowed, spinner never stopsReliability

    When a request fails, users see a spinner that never ends or an empty list, assume the app is broken or their data is gone, and nobody on your side hears about it.

    Medium
  • No backup that has ever been restoredData integrity

    When data is deleted or corrupted, whether by a bug, an agent or a person, there is either nothing to restore or a backup nobody has proven they can actually bring back.

    High
  • No automated checks before deployDeploy and config

    Type errors, broken imports and failing behaviour are discovered by users after deploy rather than by a machine before it, and each fix is another untested push.

    Medium

Questions

why does my replit app go down until i restart it

Replit's docs describe a Reserved VM as a dedicated machine that never sleeps, but a machine that stays on is not the same as a process that restarts after a crash. If the code inside throws an unhandled error and exits, nothing brings it back unless a process manager or the platform does. Check the deployment type and what happens when the process exits.

what is a restart policy for a server

A restart policy is the rule that decides what happens when your app's process stops. Docker's docs list no (the default), on-failure, always and unless-stopped. With the default, a crashed container stays stopped. Process managers such as pm2 and systemd offer the same choice for plain servers.

should i use autoscale or reserved vm on replit

Replit's docs describe Autoscale as adding servers when the app is busy and dropping to zero when idle. They describe Reserved VM as a dedicated machine for apps that must run continuously, such as bots or long tasks. Autoscale suits web apps that answer requests. Whichever you choose, the app still needs to handle its own errors so one bad request does not end the process.

Back to the catalogue, or run the self-check for your stack.