Log Mic / Field guide

Good logs start with better questions.

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.

BETTER LOGS — original Logmic.com typography artwork for Log Mic

Start with the purpose

A record should help someone decide what to do.

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.

Use logs alongside metrics and traces. A detailed event can explain an individual occurrence, while aggregate measurements and request paths answer different questions.

Four decisions to make

Put the idea into practice.

What happened?

Name the completed event or state change. Prefer a stable event name over a sentence whose wording changes with every request.

What connects it?

Keep the narrow correlation key that joins the relevant work. Document where its lifecycle starts and ends.

How certain is it?

Distinguish an observed value from an estimate. Represent missing data explicitly instead of quietly replacing it with zero.

What follows?

Decide which action the record supports: debugging, review, reconciliation, or an operational check.

A starting checklist

  • Define the question before choosing fields.
  • Separate event time from collection time when the distinction matters.
  • Choose stable event names and consistent outcome values.
  • Give every schema change an owner and a version policy.
  • Exercise one failure path and read the resulting records together.

Continue in the lab.

Make your next log a useful one.

Start with the fundamentals, then follow the signal that matters to your work.

Explore Log Mic