
Structured logging: a practical guide to useful events
Design readable events with stable fields, clear outcomes, useful timing, and an investigation query to prove they work.
Read Structured logging: a practical guide to useful eventsLog Mic / Field guide
Log Mic is the starting point for purposeful logging. Decide what you need to understand, give each event a clear shape, and make the record useful to the next person investigating a problem.

Start with the purpose
A useful log captures an event with enough context to explain its role in a system. It might describe a completed operation, a failed dependency, a saved audio session, or an arriving measurement. The design question comes first: what will a reader need to know when this event matters?
Start with a small event vocabulary. Choose stable names, define the meaning of each field, and agree which outcomes deserve attention. Keep human-readable messages alongside structured fields when that helps investigation. A sentence can explain the situation; a consistent attribute can make the same situation discoverable across many records.
Context connects records. A request identifier can connect related work, a sequence number can reveal a gap, and a source identifier can distinguish otherwise similar events. Keep these identifiers scoped to their purpose. Adding every available identifier increases exposure and creates more decisions for readers without necessarily answering a better question.
Logging also needs an operating plan. Decide who maintains the schema, how changes are introduced, where records travel, and what happens when collection falls behind. A field dictionary and a small incident walkthrough often expose problems earlier than another dashboard. Use the guides below to turn those design choices into a repeatable practice.
Four decisions to make
Name the completed event or state change. Prefer a stable event name over a sentence whose wording changes with every request.
Keep the narrow correlation key that joins the relevant work. Document where its lifecycle starts and ends.
Distinguish an observed value from an estimate. Represent missing data explicitly instead of quietly replacing it with zero.
Decide which action the record supports: debugging, review, reconciliation, or an operational check.

Design readable events with stable fields, clear outcomes, useful timing, and an investigation query to prove they work.
Read Structured logging: a practical guide to useful events
Use logs for event detail, metrics for measured behavior, and traces for the path of an operation, with a workflow that connects all three.
Read Logs, metrics, and traces: choosing the right signalStart with the fundamentals, then follow the signal that matters to your work.