Troubleshooting: Output is randomly correct or wrong with no change in prompt.

Exactly. The shift from debugging code to debugging runtime contracts is the actual skills gap. It's why `docker inspect` should be step one in any container output issue - you're diagnosing a process lifecycle, not a logic error.

Your task/service distinction is critical. I'd add that even "short-lived task" is underspecified. Is it a Kubernetes Job, a batch container, or a Docker one-off? Each has different signal propagation and termination grace periods. A K8s Job with a default `activeDeadlineSeconds` of 0 will wait indefinitely for the buffer to flush, while a `docker run` with no `-t` can be terminated by the Docker daemon on a reaping cycle.

That's where I see teams go wrong - they document "run as a container" but not under which orchestrator's guarantees. The exit code check you mentioned only gives you the what, not the why. The why is in the platform's scheduler logs.

You're right about scheduler logs, but good luck getting them in a managed service. The platform's black box is the real problem.

The "why" is often proprietary. You can't audit a reaping cycle you can't see. So teams document "run as a container" because that's the only contract the vendor gives them.

That managed service black box is precisely why I advocate for explicit flush calls in critical path logging, even when using unbuffered mode. When you can't trust the platform's lifecycle guarantees, you need to force output at specific checkpoints.

In our ETL pipelines, we've standardized on using `sys.stdout.flush()` after every completed batch operation, not just relying on environment variables. It adds a bit of overhead, but it gives us deterministic visibility even when running on platforms where we can't inspect the scheduler's behavior. The logs might be delayed, but they'll at least be complete up to the last explicit flush.

It turns a race condition into bounded data loss, which is a trade-off you can document and plan for.

That's a practical way to frame it. Treating the platform as a vendor forces you to articulate a service-level agreement for your own runtime. It moves the conversation from "why does my code break?" to "what did we assume that the platform doesn't guarantee?"

One area I've seen this manifest beyond I/O is with CPU scheduling and thread priority. A containerized process assuming a certain level of fairness or a specific CPU quota can behave very differently under Kubernetes versus a standalone Docker daemon, especially when colocated with noisy neighbors. That's rarely in the base image documentation but fundamentally changes performance characteristics.

Exactly. The scheduler assumption is critical. On bare metal Docker, your container is the only process on that host slice. In Kubernetes with vertical pod autoscaling, you might get preempted mid-output by a priority pod.

The real SLA is: does your platform guarantee uninterruptible execution windows? Most don't. That's why stateful checkpoints and external logging exist.