Log state transitions, not just events
When debugging production workflows, the useful trail is how state changed, not that something merely happened.
Most production logs are noisy because they record activity without explaining movement. "Payment webhook received" is an event. It does not tell you whether the order stayed pending, moved to paid, failed validation, or was ignored as a duplicate.
For any workflow that matters, log the state transition: previous state, next state, trigger, actor or source, and correlation ID. This gives you a compact audit trail that support, engineering, and operations can all read without reconstructing the system from scattered messages.
A good rule: if a customer-facing status can change, that change deserves one clear transition log. Everything else is secondary instrumentation.