Why Logs
Aren't Enough
Logs are valuable evidence, but they are a poor default interface for operational status.
When something important is unclear, teams often fall back to the same sentence: "I'm checking the logs." That is reasonable. Logs are where the details live. They can show what code path ran, what exception appeared, and which input caused a problem.
But logs are not the same thing as an operational view. They are usually written for debugging, not for answering a business question quickly. If someone wants to know whether the import finished, how many records were skipped, or which phase is currently running, a stream of log lines is often the long way around.
Logs require reconstruction
A log file asks the reader to rebuild the story. They need to search, filter, understand internal names, follow timestamps, ignore noisy lines, and infer which messages matter. That work may be fine during debugging. It is expensive during routine operations.
Status should be explicit
If a process has phases, progress, counts, warnings, and outcomes, those should be reported as first-class status. The system should not make every operator reverse-engineer meaning from implementation details.
Keep the logs
The answer is not to throw logs away. Logs are still the right place for detailed evidence. The missing piece is a layer above them: progress events, metrics, notes, milestones, and payloads that summarise what the process is doing in language the team can scan.
Make the common question cheap
OpenTrace is built around that distinction. Let logs explain the internals. Let telemetry explain the operation. The more often a team asks the same status question, the less acceptable it is for the only answer to be buried in logs.