What Are Wide Events? Observability 2.0, Without the Hype

A user emails to say the thing they just did did not work. Then another. Then sixty more. You open your dashboards and everything is green: the service is up, the database is healthy, the error rate is flat, and your logs say the request succeeded. You still have no idea why your customers are unhappy, because the one question you need to ask is the one your tooling was never set up to answer.

That gap is what “observability 2.0” and its foundation, the wide event, are meant to close.

Strip the buzzwords and it is simple. For each unit of work, one service handling one request, you emit a single structured event that carries everything you knew by the time the work finished. Not a line that says “request received” and another that says “done”. One event: the method and path, the outcome and status code, the duration, and then the context that actually matters: the user and their plan, the record they saved, the database query, the cache result, the commit the code was built from.

A real wide event has three properties: high cardinality (fields hold an unbounded number of unique values, user IDs, session IDs, request IDs), high dimensionality (a lot of fields, not three), and context (enough of it to answer a question you did not see coming). One shared request ID stitches the events from every service into one story.

Logs and metrics are good at the failures you anticipated: a slow request, an error, a missing environment variable. Those are known unknowns. They leave you stranded on the thing you could not predict until real users did something you never tested. Logs and metrics tell you there is a problem. Wide events tell you what it is.

Say posts are saving with a 201, the dashboards are flat, and yet customers insist their articles do not appear. With wide events, you ask instead of guess. Group the successful posts by whether they were published, and a wall of “published: false” appears. Group those by user, and it is not one person; it is many. Group by whether they are on a free trial, and there it is, only trial users. If your tooling marks a deploy, one more click lands you on the commit that did it. No grepping, no “who remembers writing this”. You asked the data a question, and it answered.

Here is the part the launch posts skip. This is not a 2024 invention. Engineers have called it “canonical log lines” for years: Brandur Leach wrote it up in 2016, Stripe was running it in 2019, and AWS has long called the same idea “service logs”. Charity Majors and Honeycomb did the field a service by naming the shift “observability 2.0”, but the technique underneath is a decade old. That heritage is the reason to take it seriously rather than as this quarter’s slogan. It is a pattern that survived real production, not a pitch.

If a wide event is one rich event per service, distributed tracing is what connects them. A span is a wide event. A trace is the request. Distributed tracing adds the plumbing you would otherwise hand-roll: it propagates the request ID across services, captures timing, and keeps the hierarchy of who called whom. And OpenTelemetry, for all its reputation for complexity, is mostly a way to generate these events without the boilerplate: instrument the framework, let it capture the I/O and the IDs, and add your business attributes to the span.

Wide events are not a free lunch, and anyone selling them as one is selling you something.

The tooling is half the answer. A wide event is only useful if your backend can query across any field, stores the raw events without pre-aggregating them away, returns answers in seconds, and does not bankrupt you. Emit rich events into a store that cannot do those things and you have paid the cost without the benefit. Sampling is how you keep the bill sane.

They do not replace all metrics. For infrastructure, the CPU on a box, the depth of a queue, plain metrics are cheap and exactly right. Wide events earn their keep in application logic, where the unknown unknowns live. Replace your application metrics, not your infrastructure ones.

And a wide event tells you which request was slow, not where in the code the time went. That is what profiling is for, and the two line up the moment they carry the same labels.

A structured log is not automatically a wide event. Five fields and no context is a structured log. Wide means wide.

It is not “wide events or the three pillars”, as if you have to burn one down. It is where each earns its place. If your pain is application behaviour you cannot predict, customers, hitting states you never tested, an answer hiding in one attribute, wide events are the tool, and the sooner you emit them, the sooner you can ask. If your need is cheap, steady infrastructure monitoring, metrics still win. The real cost is not the events; it is the tooling to query them, the storage discipline, and the habit of putting enough context on the event to make it worth emitting. Start with your most unpredictable service, the one that generates the most “I cannot reproduce it” tickets, and put one wide event on its critical path.

You stop staring at a chart that tells you there is a problem, and start asking your data what the problem is. That is the whole of it.

Observability was never about three pillars. It is about answering the question you did not know to ask, the one that was already costing you before you thought to look.

Sources: Honeycomb, “Time to Version Observability”; charity.wtf on observability 2.0; Boris Tane, “Observability wide events 101”; Brandur Leach, “Canonical Log Lines” (2016); Parseable, wide events versus traces decision framework.