Taming Glitch's Auto-Restart: A Practical Guide to watch.json

You edit a config file on Glitch, and your app restarts. You edit a log file your own app wrote, and your app restarts. You upload a batch of user avatars, and your app restarts five times in a row, dropping in-flight requests each time. This is Glitch's file-watching behavior doing exactly what it was told to do — the problem is that by default, it was told to watch everything.

The fix is a single file: watch.json. It is Glitch's supported mechanism for deciding which file changes trigger an app restart and which trigger a reinstall, and getting it right is the difference between a pleasant live-editing experience and an app that flaps under its own output.

How Glitch decides to restart your app

Glitch runs your project in a container and monitors the project directory for changes. When a watched file changes, Glitch re-runs your start command (the start script in package.json for Node projects). This is what powers the platform's signature "edit and see it live" loop.

The catch: any file your application itself writes — logs, SQLite databases, uploaded files, cache directories — also lives in that directory. Without a watch.json, writes from your own running process can trigger a restart, which interrupts the write, which can corrupt state or cause a restart loop. This is the single most common cause of "my Glitch app keeps restarting" reports.

The structure of watch.json

Create watch.json in your project root from the Glitch editor. It has two independent sections, install and restart, each with include and exclude glob patterns, plus a throttle value:

{
  "install": {
    "include": ["^package\\.json$", "^\\.env$"]
  },
  "restart": {
    "include": ["\\.js$", "\\.json$", "\\.html$", "\\.css$"],
    "exclude": ["^data/", "^logs/", "\\.sqlite$", "^public/uploads/"]
  },
  "throttle": 1000
}

The semantics worth internalizing:

• install — matching changes cause Glitch to re-run your install step (e.g., npm install) and then restart. You almost always want this limited to package.json and environment config.
• restart — matching changes restart the app process only. Excludes win over includes, so ^data/ protects your SQLite file even though nothing in include would match it anyway — belt and suspenders costs nothing here.
• throttle — the minimum quiet period, in milliseconds, before Glitch acts on changes. A value around 1000 means rapid successive edits (or a burst of writes) collapse into one restart instead of many.

Note the patterns are regular expressions matched against paths, not shell globs — \.js$, not *.js. A misplaced glob that silently matches nothing is a common reason a watch.json "doesn't work." Verify your expressions with a regex tester against real paths like routes/index.js before saving.

A worked example: the SQLite restart loop

The classic failure: an Express app stores data in data/app.db. Every write to the database changes a file, which triggers a restart, which kills the process mid-transaction. The app appears to work in light testing and falls over under real traffic.

The fix is the exclude list above: ^data/ removes the database directory from restart consideration entirely. After saving watch.json, verify the behavior directly: make a request that writes to the database, then check the Glitch log panel (Tools → Logs in the editor). You should see the request complete with no "Restarting" banner. Then edit a .js file and confirm the restart still happens — you want to prove both halves, not just that restarts stopped.

Trade-offs and limitations

Excluding paths trades convenience for stability: changes to excluded files no longer take effect until you manually restart (running refresh in the Glitch terminal, or toggling the app off and on). If your app reads templates or config from an excluded directory at startup, edits there will appear to "do nothing" — a confusing failure mode for teammates who don't know the watch.json exists. Document the exclusions in your README.

Also keep in mind that watch.json controls when restarts happen, not whether your app survives them. Restarts still kill the process, so in-flight requests die and in-memory state is lost. If you're persisting anything important, it belongs in a file or database your code writes defensively (atomic writes, WAL mode for SQLite), because even a perfectly tuned watch.json can't eliminate restarts — that's the platform's editing model.

Finally, watch.json is Glitch-specific. If you later move the project to a VPS or another host, the file is inert — you'll need nodemon, pm2, or systemd restart policies to recreate whatever behavior you relied on.

Actionable closing

If you take one thing away: audit what your app writes at runtime, and exclude every one of those paths in watch.json today. Set throttle to at least 1000ms, keep install narrow, and test by writing to your data store while watching the logs. Ten minutes of configuration eliminates an entire category of mysterious downtime.