Nixpacks Build Pipeline and Railway Runtime: Where Should Bottleneck Measurement Live?

Context

I'm deploying a service on Railway using the default Nixpacks builder and want to measure where deploy latency actually comes from before optimizing anything. The two components I'm trying to instrument across are the Nixpacks build pipeline (language detection, Nix store dependency caching, image build) and the container runtime hand-off (image promotion, health checks, zero-downtime cutover).

Constraints and uncertainty

Railway exposes no built-in build-time metrics API, so any timing data has to come from instrumentation I add myself. I'm also unsure how to interpret cache behavior: dependency caching appears to live at the Nix store layer rather than the npm/pip layer, so a lockfile-only change may invalidate far more than local CI would. Separately, internal DNS resolution (service-name.railway.internal) seems to add startup latency, but only after the container reports healthy, which makes it hard to attribute to either stage.

Assume the default Nixpacks builder (not a custom Dockerfile) and a recent Railway platform version; caching and health-check internals have changed before, so I'd want to verify against current behavior.

Questions

1. Is instrumenting the Nixpacks install/build phases with timestamps in deploy logs a reliable way to separate build duration from runtime startup latency, or does the log pipeline distort the numbers?
2. How can I tell whether a slow deploy is caused by Nix store cache invalidation versus the health-check/readiness gate, given that healthcheckPath and healthcheckTimeout are the only exposed knobs?
3. Do failed health-check deploys retain Nix store artifacts against project disk quota, and is that visible anywhere without the CLI?