Replit Run on Save Not Working? A Diagnostic Guide for Rebuild Failures

You edit a file in your Replit workspace, save it, and nothing happens. Or the opposite: your app restarts on every keystroke, CPU spikes, and your database connections pile up. Replit's Run on Save feature — which automatically re-runs your project when files change — fails in both directions, and the fix depends on which failure you actually have.

This guide walks through the recognizable conditions, likely causes, and ordered checks. Note that Replit's UI and feature availability change frequently, so treat menu paths as approximate and verify against your current workspace. The behaviors described here apply to standard Repls using the built-in run button flow, not custom Nix/Docker setups.

Match your symptom first

Ordered checks

Work through these in order. Each check maps to a fix in the next section.

1. Confirm the feature is on. Open your workspace tools or settings panel and look for the Run on Save (or "auto-run") toggle. If it's off, that's the whole problem.
2. Confirm your language is supported. Run on Save works reliably with common interpreted setups (Python, Node.js, and similar). If you're using a custom environment, a multi-process project, or a non-standard template, the watcher may simply not apply to your Repl.
3. Test with a trivial edit. Add a comment to your main file and save. Watch the console for a restart message. If a no-op edit triggers nothing, the watcher isn't running — go back to checks 1 and 2.
4. Read the console output on crash. A restart followed by an immediate exit almost always prints a stack trace. ModuleNotFoundError or Cannot find module means a dependency issue; a SyntaxError points at the file you just edited.
5. Inspect your run command. Open the .replit file (you may need to show hidden files in the file tree) and check the run entry. A typo or a command referencing a moved entry point will make every auto-restart fail even though manual runs once worked.
6. Check what your app writes. If your program writes logs, cache files, uploaded files, or build output into the workspace, the watcher sees those writes as changes and restarts again — a restart loop. This is the classic cause of runaway CPU.

Fixes tied to each finding

Watcher never fires

Enable the toggle in workspace settings, then verify with the trivial-edit test. If your template doesn't support it, the practical workaround is a manual run loop: keep the console visible and re-run with the Run button, or move the auto-reload concern into your stack — for example, Node.js projects can use nodemon and Python projects can use a watcher like watchfiles, configured in your run command:

# .replit (example — adjust to your project)
run = "nodemon --watch src --ext js index.js"

This moves file-watching into a tool you control, including which directories it watches. The risk: you're now responsible for the watch scope, and a broad scope recreates the same restart-loop problem one layer down.

Restart crashes immediately

Fix the error the console shows — this is rarely a Run on Save problem at all. The feature surfaced the failure faster than you would have found it manually. For missing dependencies, install them through the Replit package manager (Packages tool) rather than only editing config files by hand, so the environment actually rebuilds. After fixing, save the file and confirm the app stays up for at least a minute.

Restart loop and high CPU

Redirect runtime-generated files somewhere the watcher ignores, or stop writing them into the workspace. Concretely:

• Write logs to stdout instead of a log file in the project directory.
• Move caches and temp uploads outside the watched tree if your template supports ignore configuration.
• If your build step generates files (bundled JS, compiled assets), generate them into a directory excluded from watching, or disable Run on Save and restart manually after builds.

To verify the fix, watch the console while the app runs idle for a few minutes. You should see zero restart messages when you haven't edited source files. Also check the workspace resource indicator — CPU should settle to near baseline between edits.

External services failing on restart

Repeated restarts can exhaust database connection pools or hit API rate limits. Two mitigations: add graceful shutdown handling so connections close before exit (for example, an SIGTERM handler that closes your database pool), and reduce restart frequency using the loop fixes above. If the external service shows stale connections after restarts, the missing piece is shutdown handling, not the watcher.

When to escalate

Stop troubleshooting locally and report or ask for help when:

• The toggle is on, the language is standard, a trivial edit produces no console activity, and a fresh Repl with the same template works — that suggests a workspace-level issue worth reporting to Replit support.
• Resource usage stays pinned even with Run on Save disabled — the watcher isn't your problem and something else in the Repl is consuming CPU.
• Behavior differs between collaborators on the same Repl, which points to a platform-side inconsistency rather than your configuration.

Before escalating, capture the console log from a failed restart and note your template and run command. That turns a vague "auto-run is broken" report into something support can act on.