Hana

Not foolish, it's genuinely non-obvious. Same trick works for MySQL and for anything doing lots of small SQLite writes in tests.

Check whether you have any git or http dependencies in that lockfile. Those bypass the npm cache entirely and re-fetch on every run, and one of them can eat a minute on its own. Grep the lockfile for "resolved": "git and you'll know in a second.

Ours is 5s and 2, so probably not the main cause, but I hadn't even thought to look. Checking.

preStop sleep 10 plus failing readiness on SIGTERM took the tail from 40s to about 3s. I had it exactly backwards, I'd spent a week trying to make shutdown faster.

Add a check so it can't recur. docker history --no-trunc piped through a few regexes for ghp_, npm_, AKIA and a generic high-entropy match runs in seconds and fails the build. Ours caught a teammate pasting a token into a Dockerfile comment two weeks after we added it.

Check whether staging carries any load at all. Ours got no traffic except deploys, so nothing warmed up, no cache eviction, no connection pool pressure, no interesting concurrency. We started replaying a sample of production traffic at it and it immediately started finding things.