---
title: "Log cost"
description: "One request leaves one event instead of four lines: 56% fewer bytes, 75% fewer events. Which number moves your bill depends on your provider."
canonical_url: "https://www.evlog.dev/reference/cost"
---
# Log cost

> One request leaves one event instead of four lines: 56% fewer bytes, 75% fewer events. Which number moves your bill depends on your provider.

Log bills scale with what you send, and a logger that writes a line per step sends the same request context over and over. Every line carries its own level, timestamp, host, and request bindings. Four lines, four copies.

evlog emits one event per request instead, so that context is written once. This page measures the difference and lets you price it against your own traffic.

## Try it against your numbers

<log-cost-calculator>



</log-cost-calculator>

## Where the byte counts come from

Both shapes are the checkout request documented on [Performance](https://www.evlog.dev/reference/performance), serialized through the real libraries rather than estimated.

<code-group>

```typescript [evlog, 1 event of 322 B]
const log = createLogger({ method: 'POST', path: '/api/checkout', requestId: 'req_abc' })
log.set({ user: { id: 'usr_123', plan: 'pro' } })
log.set({ cart: { items: 3, total: 9999 } })
log.set({ payment: { method: 'card', last4: '4242' } })
log.emit({ status: 200 })
```

```typescript [pino, 4 lines of 736 B]
const child = pinoLogger.child({ method: 'POST', path: '/api/checkout', requestId: 'req_abc' })
child.info({ user: { id: 'usr_123', plan: 'pro' } }, 'user context')
child.info({ cart: { items: 3, total: 9999 } }, 'cart context')
child.info({ payment: { method: 'card', last4: '4242' } }, 'payment context')
child.info({ status: 200 }, 'request complete')
```

</code-group>

<table>
<thead>
  <tr>
    <th>
      
    </th>
    
    <th align="right">
      Events
    </th>
    
    <th align="right">
      Bytes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      pino, 4 lines
    </td>
    
    <td align="right">
      4
    </td>
    
    <td align="right">
      736
    </td>
  </tr>
  
  <tr>
    <td>
      evlog, 1 event
    </td>
    
    <td align="right">
      1
    </td>
    
    <td align="right">
      322
    </td>
  </tr>
  
  <tr>
    <td>
      Difference
    </td>
    
    <td align="right">
      <strong>
        75% fewer
      </strong>
    </td>
    
    <td align="right">
      <strong>
        56% fewer
      </strong>
    </td>
  </tr>
</tbody>
</table>

The two numbers differ because consolidation removes duplicated envelope, not payload. `level`, `time`, `pid`, `hostname`, `method`, `path`, and `requestId` are written four times by pino and once by evlog, and the four `msg` strings disappear entirely. The fields you actually set are written once either way.

<callout color="warning" icon="i-lucide-alert-triangle">

Your ratio is not this ratio. A handler that logs two lines saves less; one that repeats a large `user` object on every line saves more. The method transfers, the number does not.

</callout>

## Which number moves your bill

Providers meter logs in one of two ways, and that decides which saving you actually collect.

<table>
<thead>
  <tr>
    <th>
      Metered by
    </th>
    
    <th>
      Saving you collect
    </th>
    
    <th>
      Providers
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Gigabytes ingested
    </td>
    
    <td>
      The <strong>
        56%
      </strong>
      
       byte figure
    </td>
    
    <td>
      Grafana Cloud, Sentry, PostHog, Better Stack, Axiom
    </td>
  </tr>
  
  <tr>
    <td>
      Gigabytes <strong>
        and
      </strong>
      
       indexed events
    </td>
    
    <td>
      The <strong>
        75%
      </strong>
      
       event figure, on the line item that usually dominates
    </td>
    
    <td>
      Datadog
    </td>
  </tr>
</tbody>
</table>

Per-gigabyte billing is the common case, so most teams collect the byte saving. Datadog is the outlier worth checking: it bills ingestion per gigabyte and indexing per million events, and at production volumes the indexing line is the larger of the two, so the event count is what moves.

Rates were read on 14 August 2026 and are list prices, before free tiers, committed-use discounts, and retention add-ons. They are inputs in the calculator above for exactly that reason.

## Sampling moves both columns

The calculator applies sampling to both shapes, which is the only fair way to model it. Dropping events is not something evlog does and other loggers cannot: you can filter by level in any logger, or sample in the transport. Applying it to one side only would flatter evlog with a saving that is not evlog's. Pull the slider down and both bills fall together while the gap between them holds.

It is still the larger lever. Consolidation is bounded, because you cannot send fewer than one event per request. [Sampling](https://www.evlog.dev/learn/sampling) is not: head sampling drops events by level at emit time, and tail sampling force-keeps the ones you would have wanted, so errors and slow requests survive a rule that discards the rest. Volume stops tracking traffic and starts tracking signal, which is the only version of this that keeps working as you grow.

What evlog changes is the unit sampling operates on. Dropping a line loses part of a request; dropping an event loses a whole one, and keeping an event keeps all of it.

## Ask it from your editor

The same calculation is an MCP tool on this site's server, so an assistant connected to the [docs MCP server](https://www.evlog.dev/reference/mcp) at `https://www.evlog.dev/mcp` can answer it directly:

```text
estimate-log-cost({ requestsPerMonth: 10000000, linesPerRequest: 4, provider: "datadog" })
```

It returns both shapes, the saving, and the basis it used: the measured byte counts, which rates it applied, and the date those rates were read. Pass `perGb` and `perMillionIndexed` to price a provider that is not in the list, or to correct one whose pricing has moved.

## Next

- [Sampling](https://www.evlog.dev/learn/sampling): the two tiers, and what each one costs you in visibility
- [Performance](https://www.evlog.dev/reference/performance): the benchmarks these byte counts come from
- [Drain adapters](https://www.evlog.dev/integrate/adapters/overview): every destination, and how to change your mind later

---

- [Performance](https://www.evlog.dev/reference/performance)
- [Sampling](https://www.evlog.dev/learn/sampling)


## Sitemap

See the full [sitemap](https://www.evlog.dev/sitemap.md) for all pages.