# Wide Events vs Metrics, Logs and Traces: What Observability 2.0 Costs

> Wide events move observability cost instead of removing it. See what each signal is billed in, which question each answers cheapest, and how to size spend against cloud spend.

Source: https://last9.io/blog/wide-events-vs-metrics-logs-traces-cost/

Wide events are one structured record per request, with dozens of fields on it. The argument for them, which people now call observability 2.0, is that this one record can answer what separate metrics, logs and traces answer, so you can stop paying for three stores. The argument against is the bill: a record that wide, for every request, is not free either.

This post follows observability cost by billing unit (series, bytes, spans, event width) and asks which question each signal answers cheapest. We have no Last9 data on cost per signal or on what share of cloud spend observability takes, so the post doesn't invent any. Where a number appears, it is a documented limit, an arithmetic example we label as one, or a single comment from a public thread.

## Do wide events replace metrics, logs and traces?

Not entirely, and they don't remove the cost. They move it. Each signal is billed in a different unit, and the unit decides what grows the bill:

- **Metrics** are counted in series: every unique combination of label values.
- **Logs** are counted in bytes: line length times lines written.
- **Traces** are counted in spans: spans per request times requests.
- **Wide events** are counted in event width times request volume: fields per record times requests.

The cheap choice depends on the question you ask most often. If it is "is it healthy" with an alert behind it, metrics cost least. If it is "which customers are hit", a wide record earns its width. Our guide to [metrics, events, logs and traces](/blog/understanding-metrics-events-logs-traces-key-pillars-of-observability/) covers what each signal is. This post is only about what each one costs.

## What is a wide event, and what does observability 2.0 claim it replaces?

A wide event is a structured record emitted once per unit of work, usually one request, with every field you might later filter on: user ID, route, build, region, feature flag, status, duration, downstream calls. It is a log line with a schema and far more fields, or a span with the request's business context attached.

The observability 2.0 claim is that you keep the raw record and derive everything else from it at query time. Counts and rates come from aggregating events. A request's story comes from the fields on its record. No pre-aggregation step decides in advance which questions you can ask.

The trade is storage and scan cost against flexibility. Pre-aggregated metrics are cheap because they throw the request away and keep a number. [OpenTelemetry's signals documentation](https://opentelemetry.io/docs/concepts/signals/) describes metrics, logs and traces as separate signals with different shapes. A wide event cuts across all three, which is useful and is also why it is the largest record you store per request.

## Where does observability cost go, signal by signal?

Take the same service and ask what grows each bill.

**Metrics: series count.** A metric with labels for 5 routes, 4 status classes and 10 pods has 200 series. Add a `user_id` label with 100,000 users and it has 20 million. Storage per series is small, but on a per-series meter that one label is a pricing event. This is the cost our guide on [high cardinality](/guides/high-cardinality/what-is-high-cardinality/) is about.

**Logs: bytes and verbosity.** Cost follows line length times lines written. A `DEBUG` level left on in production or a noisy dependency logging every retry does more damage than a new label. Our [logs vs metrics guide](/blog/logs-vs-metrics/) covers when each one earns its place.

**Traces: spans per request.** Every operation adds a span, so instrumenting another client library raises cost with no change in traffic. Sampling is the usual lever, and it is also how the one trace you needed goes missing.

**Wide events: width times volume.** One record per request is fewer units than one span per operation, but each record is bigger. Take 20 requests a second over a 30.4-day month, the example in our [Honeycomb pricing post](/blog/honeycomb-pricing/). At 15 spans per request that is about 788 million spans. One wide event per request is about 52.5 million events, roughly one fifteenth the count.

That fifteenfold gap only counts as a saving if the wide event replaces the spans and logs. If it sits next to them, you have added a fourth copy of the request, which is the next section.

Vendors also meter signals differently, which changes which row hurts. Our [cloud cost management guide](/blog/cloud-cost-management-for-observability/) tabulates one vendor's separate meters for hosts, custom metrics, log GB and events, and sorts them by what makes each one grow.

## Which question is each signal cheapest to answer?

Choose the signal by the question, then check what breaks its cost.

| Question | Cheapest signal | Why | What breaks the cost |
| --- | --- | --- | --- |
| Is the service healthy? | Metrics | One number per series per interval, however many requests | A new label multiplies series |
| Is one route's error rate climbing? | Metrics | Pre-aggregated, so a query reads a few series | Per-request labels such as user ID |
| Which users or builds are affected? | Wide events | One record holds user, build, route and outcome | Field count, and keeping every request |
| Where did this request stall? | Traces | Spans carry per-operation timing | Spans per request, and sampling |
| What did this host print? | Logs | Raw text, no schema decided in advance | Verbosity and retention |

A wide event can answer the first two rows, but it answers them by scanning events at query time. A metric answers them from a series that was already summed. That is why many teams that adopt wide events still keep metrics for alerting.

## What is the duplication tax of keeping all three?

The tax is paying to store one request three or four times. A checkout request leaves a metric sample, a log line, a span per operation and, if you add them, a wide event.

In the public discussion behind this post, one commenter put the cost side directly: [paying for servers to store that amount of duplication is a real issue](https://news.ycombinator.com/item?id=50236111), and separate stores for metrics and documents exist because of cost and query needs. That is one engineer's view, not a measurement.

We haven't measured a storage multiplier for duplicating one request across signals, and we don't know of a verified figure. To size your own, pick one busy endpoint and list what it writes to each store per request. Then compare the bytes, series and events. The list shows which fields you write twice.

## How much of cloud spend should observability take?

No verified benchmark exists, and the figures in the same public thread disagree. They are single comments, so read them as anecdotes:

- One commenter wrote that [their observability stack takes 20 percent of cluster operation costs, 40 percent of license costs and 25 percent of salary costs](https://news.ycombinator.com/item?id=50236805), and was not pleased about it.
- Another reported [about 10 percent of their cloud spend on observability, and a target of 15 percent](https://news.ycombinator.com/item?id=50236840).

Neither tells you what is healthy for your system. Compute your own share, and include the parts that never show up on the vendor invoice:

```text
observability share = (vendor bills
                     + infrastructure you run for observability
                     + engineering time spent on it)
                     / total cloud spend
```

Here is the arithmetic with round numbers we made up for the example, not a benchmark. Say cloud spend is $400,000 a month and observability costs $36,000 a month in total. The share is 9 percent. Then split it by signal to see which line to question first:

| Signal | Monthly cost | Share of cloud spend |
| --- | --- | --- |
| Metrics | $8,000 | 2.0% |
| Logs | $16,000 | 4.0% |
| Traces | $9,000 | 2.25% |
| Everything else | $3,000 | 0.75% |

The split matters more than the total. Our cloud cost guide recommends setting a budget per signal type, not just a total, so that a rise points at a cause. A wide-event store with no per-signal split hides the same information.

## How do you choose by question, not by pillar?

Start from your top five questions during incidents and pick the cheapest signal for each, using the table above. Then apply these rules:

- **Alerts on metrics.** Alerts run on a schedule against pre-aggregated series. They should not scan raw events every minute.
- **Slicing on wide records.** Use them for "which users, which build, which region". Keep the field set deliberate, because width is the bill.
- **Latency on traces.** Keep span depth to operations someone queries.
- **Convert before you store.** If a high-volume log exists only to feed a count or a rate, turn it into a metric at ingest and drop the raw lines.

On Last9, streaming aggregation transforms incoming telemetry into metrics before storage, and LogMetrics converts logs into metrics you can alert on. The docs also give tuning guidance: query response times for a metric start degrading beyond a daily cardinality of about 3M series, and they advise keeping per-metric daily cardinality inside that using streaming aggregation. Aggregation loses detail, so keep the raw records for questions that need them.

## How do we keep the choice cheap at Last9?

We make no claim here that Last9 stores wide events as a native record type. What we document is narrower and sits underneath the choice. We keep high-cardinality labels with no sampling, so you can slice a metric by customer or request ID. There is no hard limit: 20M series per metric per day by default, raised on request, without sampling, and we do not charge per label or metric name.

Billing follows the same logic. Last9 is one licence, and the infrastructure runs on your own cloud bill at your negotiated rates. There is no meter per active series or per GB, so a new label doesn't change the line item.

The controls sit at ingest. Our [Control Plane](/docs/control-plane-ingestion/) drops, remaps, redacts, forwards and aggregates telemetry before storage and previews every rule against live data before you save it. For storage, [metrics tier automatically](/docs/control-plane-storage/): Blaze for the last 2 hours, Hot for the last 28 days, then cold storage. Default retention is 90 days for metrics and 14 days for logs and traces, with cold storage behind them. The [high cardinality docs](/docs/managing-high-cardinality/) list the limits, and the [streaming aggregation docs](/docs/streaming-aggregations/) show how to build the rules.

When is another tool the better fit? Honeycomb is organised around wide events and is strong at ad hoc exploration of high-cardinality event data. It bills per event, where every span counts and Pro is $3.00 per million events since July 2026, as we cover in our [Honeycomb pricing post](/blog/honeycomb-pricing/). If your questions are event-shaped and you can run sampling, it fits well. If you want metrics, logs and traces on one licence, with every trace kept and ingest-time control, our [Last9 vs Honeycomb comparison](/compare/honeycomb/) goes through the differences.

## FAQ

### Do wide events replace metrics, logs and traces?

Not entirely. A wide event answers questions about individual requests well, such as which users or builds are affected. Health checks and alerts still run cheapest on pre-aggregated metrics, and raw logs and request-level traces still cover things a single request record does not hold. Many teams that store wide events still keep metrics for alerting, and they stop paying twice only when they stop writing the same fields into logs and spans.

### Are wide events cheaper than separate signals?

It depends on the billing unit. If a vendor bills per event, one wide event per request can mean far fewer billable units than one span per operation, but each event carries many fields. If you keep wide events in addition to logs and spans, you store the same request several times and the bill goes up. We have no Last9 data on cost per signal, so treat any fixed multiple you read as unverified.

### Why do metrics cost less to store and query than logs?

A metric stores one number per series per interval, so a counter takes the same space whether it counts ten requests or ten million. Cost grows with the number of label combinations, not with traffic. Logs and events grow with every request and every field written, and an error rate computed from raw records scans those records at query time. We have not measured a specific multiple, so this is a mechanism, not a benchmark.

### What percentage of cloud spend should go to observability?

There is no verified benchmark. In the public discussion behind this post, one commenter reported about 10 percent of cloud spend on observability and a target of 15 percent, and another described a stack taking 20 percent of cluster costs. Those are single comments. Work out your own share by dividing vendor bills, the infrastructure you run for observability and the engineering time by total cloud spend, then split it by signal.

### How does cardinality affect the cost of each signal?

Cardinality drives metric cost most directly, because every unique label combination is a new series. Adding a user ID label to a metric with 200 series and 100,000 users produces 20 million series. Logs and wide events are less sensitive to it, since a high-cardinality field is just another value in a record. On Last9 the default is 20M series per metric per day, raised on request, without sampling, and we do not charge per label or metric name.

### Should cost decisions be made before or after data is stored?

Before, where you can. Dropping, aggregating or converting telemetry at ingest settles the cost once, instead of fighting a growing stored dataset. Converting high-volume logs to metrics before storage keeps the question answerable at a fraction of the volume. Aggregation loses detail, so keep raw records for the questions that need them and preview any rule against live data before you save it.