A nightly reconciliation batch keeps retrying and its output stream is completely empty — has the process ever run?

## What an empty stream can mean The log contract for a container is the process's own standard output and error streams, captured by the platform. So "the stream is empty" is a statement about your process, and it is consistent with three quite different situations: - **Nothing was ever created.** The node could not obtain the image — an unauthenticated fetch, a rate limit applied by the registry, a reference resolving nowhere, or nothing matching the node's processor architecture. There was never a process to write anything. - **The start was refused.** The image is there and the runtime could not construct a running process: a value the spec references does not exist, a mount could not be attached, or the declared command is not at the path given. Again, nothing of yours ran. - **The process ran and wrote nothing.** It failed on its very first action, or it buffered its output and the buffer was never flushed because the exit was abrupt. The first two are far more common than the third, which is why an empty stream is a useful signal. It is not a proof, and treating it as one sends people to rewrite start-up code that never executed. ## Absence of a stream against an empty stream There is a distinction worth making explicitly, because the two look the same in a hurry: | What you see | What it suggests | What to confirm | |---|---|---| | No stream exists for this instance at all | no process was ever created | which step reported the failure | | A stream exists and holds nothing | a process may have been created and written nothing | whether a termination record exists | | A stream holds lines from an earlier instance only | a process ran at least once before | whether the current instance is younger than its first write | That last row matters more than it looks. An instance that has existed for two seconds and writes its first line after loading configuration is indistinguishable, at the moment you look, from one that will never write anything. Look twice, a few seconds apart, before concluding. ## Who wrote the message you are reading The fastest discriminator on this whole subject is authorship, not content. Three different actors produce messages during a start: 1. **The node agent's fetch step**, which reports what happened while obtaining the image. Anything from here means no process ran. 2. **The runtime's start step**, which reports why it could not construct or launch the process. Anything from here means no code of yours ran, and the message names the thing it could not resolve — a value, a mount, a command. 3. **Your process**, whose output appears in the captured stream. Anything at all here proves the first two stages were passed, however useless the line itself is. A candidate who reaches for the third and finds it empty, and then asks *who else has spoken*, gets to the stage in one more step. A candidate who only reads the empty stream has no next move and usually invents one. ## What settles it - **A termination record** for this instance, or for the one before it, proves a process ran — only something that started can terminate. - **Output retained from a previous instance** proves the same thing, and pushes the diagnosis to a process that dies rather than one that never starts. - **A message from the fetch or start step** settles the opposite direction. - **A second look a few seconds later** distinguishes an instance that writes late from one that never writes. Platforms differ in how much they retain from a replaced instance, so do not build a triage habit that depends on always having the previous instance's output; treat it as a bonus when it is there. ## The mistake this evidence invites The common wrong turn is to read emptiness as loss: "the collector must have dropped it". Collection can indeed lose lines, and that is a real subject — but it is the wrong first hypothesis here, because it explains the evidence only by assuming a second, independent failure at the same moment. The parsimonious reading of an empty stream on a workload that never reached running is that nothing wrote to it. Rule out the two stages that produce no writer before you suspect the reader. The second wrong turn is the inverse: concluding from emptiness that the process definitely never ran, then rewriting the wrong thing. State the finding honestly — *no evidence a process ran* — and go get the one observation that turns it into a conclusion.