Wide events

A wide event is one event per request, or per unit of work, that carries many fields at once: the user, plan, region, feature flags, build version, database timing and downstream status. The alternative is many narrow log lines, plus metrics aggregated separately. A wide event keeps everything about one request in one row, so you can slice by any field afterward.

The idea was popularized by Honeycomb, and it is sometimes called a canonical log line.

The big idea

Think of a survey. Narrow logs are like counting "yes" answers to one question at a time. A wide event is the completed survey form. With the forms, you can ask "of the people who answered no, how many were on the new plan and in the EU?" The form had all of those answers already.

Walking through it

The debugging loop looks like this:

1. Start from the symptom. For example, p99 for checkout doubled.
2. Break the slow requests down by a field that separates them most, such as build_id, region or a feature flag.
3. Repeat with the cohort you found, until one group explains the failure.

Suppose the breakdown shows that every slow request has build_id = 2026.03.14-b and region = eu-west. You now have a small group to check, not a whole graph to stare at. Traces still matter for causality across services. Wide events matter for finding which group is broken when the overall graph looks healthy.

You do not need a vendor to start. A single structured log line at the end of each request, with every dimension you wished you had during the last incident, is already a wide event. Put the same fields on the root span, so traces and logs agree.

Common mistakes

• Writing one event per function call. The point is one row per request, or per unit of work, so the row answers a question about the whole request.
• Leaving out the dimensions you wish you had. Add them while you are fresh from an incident. The next outage will need them.
• Keeping PII in the event. The same privacy rules that apply to logs apply here. See logs, cost and privacy.

Check yourself

1. Why does a wide event help when averages look normal? It keeps every field for each request, so you can find the group that is broken even when the overall average hides it.
2. What is the cheapest way to start? Emit one structured log line at the end of each request, with all the fields you would need in an incident.

Key takeaways

• A wide event is one rich record per request, not many narrow lines.
• Find the broken cohort by breaking down on the fields that separate fast from slow.
• You can start with a single structured log line and add a vendor later.

Further learning

The trace side, which shows causality across services, is in distributed tracing. The field conventions are in structured logs.