Log every dependency version at startup. That's it. That's the post.

I have one piece of advice that has paid for itself, in debugging hours saved, more times than I can count.

When your service starts up, log the version of every external dependency you can identify.

That's it. That's the whole tip.

Database client version. HTTP client version. Major library versions. The runtime version. The OS kernel version, if you can get it. Whatever specific cloud SDK version is loaded. Print it all to your structured log under an application_startup event the first time the process boots.

Why?

Because every single time something works in staging and breaks in production, the very first question I want answered is "what is different about the running binary in those two environments?" And nine times out of ten, the answer is buried in a transitive dependency that resolved to a different version under different lockfiles, base images, or build environments.

I once spent two days chasing a flaky test in a CI environment that turned out to be a glibc version mismatch between the runner image and our app's Docker base. The fix was twenty seconds. The investigation was forty-eight hours.

Another time, a payment integration started silently failing for 0.4% of charges in production while passing every staging test. Eventually we traced it to a Stripe SDK that had been silently bumped from 12.x to 13.x two deploys earlier, and the new version had stricter idempotency-key validation. The startup log of the production process said nothing because we hadn't been logging the version. We had to git blame our way to it.

After that incident I added the dependency-version dump to every service I've shipped. It costs nothing. The log line is generated once per process start. The version string is whatever the package manager already knows. There is no runtime overhead.

What it gives you, the first time something behaves differently between two environments, is the ability to do a literal text diff of the two startup logs and read your own answer back.

Concretely

In a Node service it's something like:

import pkg from "./package.json" with { type: "json" };

log.info({
  event: "application_startup",
  service_version: pkg.version,
  node_version: process.version,
  platform: process.platform,
  arch: process.arch,
  // include whatever else: ENV, REGION, etc.
});

In Python, walk pkg_resources.working_set once at boot. In Go, runtime/debug.ReadBuildInfo(). In every language there is a one-liner that gives you a snapshot of the universe the process woke up in.

If you take exactly one piece of advice from any blog post you read this week, take this one.