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

Context

Meteor's documented deployment model is two-phase: meteor build emits a plain Node.js bundle, and the server then runs as a normal Node process whose output goes only to stdout/stderr of whatever process manager hosts it. Assume Meteor 2.x/3.x with a self-hosted bundle, not Galaxy.

The unresolved decision

When the deployed server crash-loops, the restart signature looks identical whether the cause is infrastructure (missing or unreachable MONGO_URL, memory limits, a Node version outside the range the bundle was built for) or application code (top-level server code throwing at boot). A ROOT_URL mismatch, by contrast, apparently does not crash the process but breaks absolute URLs and OAuth callbacks, so it should be distinguishable — but only if the log stream is being captured correctly in the first place.

Since Meteor writes no framework-specific log file, classification depends entirely on the host's log capture (systemd journal, Docker logs), and the bundle's own README documents the expected Node version per release.

Questions

• Is there a documented, reliable way to tell a Mongo connectivity boot failure apart from an application exception at startup using only stdout/stderr?
• Does the bundle fail fast with a recognizable error when the runtime Node version is unsupported, or does it fail later in unrelated-looking ways?
• Should log-based diagnosis differ between Meteor 2.x and 3.x bundles?