I Updated n8n, Everything Looked Fine, and One Workflow Quietly Stopped Running

An n8n update finished the way every update before it had — clean logs, a healthy API check, nothing that looked like a failure. The only thing that gave away that something had actually broken was a headcount, and it was one number lower than it should have been.

What a routine update actually looks like

n8n on this box runs as a plain Docker container, not docker-compose, so an update means pulling the new image and recreating the container with the same volumes, environment variables, and port mapping — the workflow data itself lives in a separate named volume, independent of the container's own lifecycle. Pull, stop, remove, run again with the same flags, confirm the API responds. That part went exactly as expected.

The check that almost didn't happen

Out of habit more than suspicion, the active-workflow count from before the update got compared against the count after. Before: 34. After: 33. Nothing in the startup log had flagged an error, and the API health check had already come back green — the only reason this surfaced at all was a manual before-and-after comparison that isn't part of a normal health check.

What the new version had actually changed

This version's release included database migrations affecting how schedule triggers are stored internally. One specific schedule-triggered lead-gen workflow got flipped to `active: false` by that migration — not a crash, not a corrupted workflow, just quietly turned off as a side effect of the schema change. It would have simply never run again, silently, until someone happened to notice its daily output had stopped.

The fix was almost anticlimactic

A single `POST` to the workflow's activate endpoint turned it back on immediately — no data loss, no reconfiguration, count back to 34. The hard part was never fixing it; it was noticing it needed fixing at all, since every other signal available said the update had gone perfectly.

A second, unrelated mistake from the same job, worth keeping separate

Earlier in the same update process, the container recreate command got run *through* an n8n workflow using an SSH-node shortcut — which meant the `docker stop` command was executed by a process running inside the very container it was told to stop. The stop succeeded, killed its own execution before it reached the following `rm`/`run` commands, and left the container stopped but never recreated. Recoverable by finishing the remaining commands manually from outside, but the actual lesson is narrower than "be careful with docker": any command that touches a container's own lifecycle needs to run from somewhere that isn't inside that same container, full stop.

What to check after any future update

Snapshot the active-workflow list before updating, compare it after — not just whether the API responds, but the actual count and which ones are active. A version bump that touches internal schema or trigger storage can deactivate something without logging an error, and a clean startup log is not the same claim as "nothing changed."