meteor build output moved to plain Node: which startup failures belong to the bundle and which to my code?

Direct Answer

Yes, you can reliably distinguish bundle-origin failures from application-code crashes using only stdout/stderr, provided the first crash output is preserved. The discriminator is the stack-trace origin: infrastructure errors point into Meteor core packages or the Node runtime, while application errors reference your project files.

Confirmed Facts

• Mongo connectivity failures surface early in the boot sequence, before any Meteor.startup callback runs. Stack traces reference packages/mongo/ or the mongodb driver. Default retry options retryWrites and retryReads can add a few seconds' delay, making the failure appear later than it actually is.
• Node version mismatches behave differently by major version. Meteor 3.x bundles include an explicit version check at the top of generated main.js that prints This bundle requires Node >= X.Y.Z and calls process.exit(1) immediately. Meteor 2.x bundles have no such check; they start but later produce cryptic SyntaxError or TypeError from modern JavaScript syntax (optional chaining, nullish coalescing) that was only transpiled for the target Node version, with stack traces pointing into vendor chunks, not your code.
• A ROOT_URL mismatch never crashes the process; it only corrupts absolute URLs and OAuth callbacks, so no startup error appears in the log.
• All fatal uncaught exceptions, regardless of source, produce an identical crash-loop signature from the host's perspective. Classification therefore depends entirely on where the stack trace originates.

Minimal Diagnostic Steps

1. Ensure your process manager captures stdout and stderr from the very first process spawn, not after restart. Systemd's rate-limit or Docker's log driver configuration can affect this.
2. Read the top of the stack trace. Paths under packages/mongo/, mongodb/, or internal Node modules indicate infrastructure failure. A message starting with This bundle requires Node indicates a version mismatch (Meteor 3.x only). Paths under your project's /imports, /server, or root filenames indicate your code.
3. Verify the Node runtime against the bundle's README.md. Run cat bundle/README.md and confirm the documented Node version matches your runtime.
4. As a quick test, start the bundle with an intentionally bad MONGO_URL and confirm the error originates from the driver, or run the bundle on a Node version below the required minimum and observe the fast-fail message in 3.x versus a delayed SyntaxError in 2.x.

One missing detail that changes the recommendation: Does your process manager log capture begin before the bundle process spawns, or only after the first restart? If the earliest output is truncated, the stack trace origin cannot be determined, and log capture must be fixed first.