Trust Game

# Would you trust this telemetry?

Each case shows real, anonymized OpenTelemetry® data and a conclusion someone drew from it. Some conclusions hold up, some don't. Make the call, then see the tell and the fix.

Play Now

Case 04 · Logs

The health-check logs are all INFO, so the checks are passing.

INFO service check got error ECONNREFUSED

INFO service check got error ECONNREFUSED

Doesn't hold up

Case 01 · Trace

The provider had no record for this customer. Our own services were fast.

OK user-profile GET /v1/users 1.2 ms

ERROR fetch provider report 1.13 s

Holds up

Ready when you are

## 10 conclusions. Does the telemetry back them up?

Someone read this telemetry and drew a conclusion. Sometimes the data is broken, sometimes the reading is. Half the conclusions hold. No timer and no sign-up.

Start the game →Make the call with Y or N, then Enter for the next case.

## How it works

- 01Read the situation

An on-call moment and the conclusion someone drew from the telemetry, the way it would come up in an incident channel.

- 02Inspect the telemetry

A trace waterfall, log records, a span, a table, a chart, or a service map, as your backend would show it.

- 03Make the call

Does the telemetry back the conclusion up? Half the conclusions hold, so doubting everything won't win.

- 04See the tell

Each reveal says whether the data or the reading was at fault, points at the detail that settles it, and shows the fix.

20 cases

## What you'll practice

20 cases across traces, logs, spans, and metrics. Each game deals 10 of them, half that hold up and half that don't.

- 01

### Span status and span kinds

When ERROR marks a real failure, and which parent and child spans may overlap.

- 02

### Log severity

Why a severity filter can come back empty while the service is failing.

- 03

### Timestamps

Event time, observed time, and what a time-range search can miss.

- 04

### Trace context

How parent and child links carry a request across services and message brokers.

- 05

### Service identity

What service.name tells you, and what an SDK default hides.

- 06

### Protocol status

Where HTTP and gRPC each report success and failure.

**Anonymized, but real.** Every case comes from production OpenTelemetry data that OllyGarden sampled and analyzed. We invented every service, host, endpoint, and ID name and removed anything that could identify the source. Status codes, span structure, and ratios are as measured.

Where will you land?

- 🍷 Telemetry sommelier 10/10
- 📟 Seasoned on-call 8–9/10
- 🧐 Healthy skeptic 6–7/10
- 📈 Dashboard optimist 4–5/10
- 🌙 Paged at 3 a.m. 0–3/10

## About the game

Where the cases come from and what OllyGarden does with telemetry like this.

### Is this real customer data?

Yes, anonymized. Every case comes from OpenTelemetry data that OllyGarden sampled from production systems. Every service, host, endpoint, and ID name is invented, and nothing identifies the source. Status codes, span structure, and ratios are kept as measured; where a timing is illustrative, the reveal says so.

### What makes telemetry deceptive?

Two things. Sometimes the data itself says the wrong thing: errors logged at INFO or with no severity, timestamps at the Unix epoch or an hour off, traces missing their root, or services reporting under an SDK default name. Sometimes accurate data is easy to misread: a gRPC failure behind HTTP 200, a long-poll wait that looks like latency, or a retry loop that looks like an outage. Queries, alerts, and dashboards inherit both mistakes. [What is telemetry quality? →](/resources/telemetry-quality)

### How does OllyGarden catch these problems?

OllyGarden Insights analyzes the telemetry you already send and flags quality problems per service, such as missing service names, single-span traces, and duplicate log records, with the fix for each. Rose reviews the instrumentation code that produces it. [Explore OllyGarden Insights →](/products/insights)

## Turn OpenTelemetry knowledge into better instrumentation

OllyGarden Insights scores the telemetry you already send, and Rose fixes it at the source.

[Explore OllyGarden Insights](/products/insights)[Meet OllyGarden Rose](/products/rose)

Canonical URL: https://ollygarden.com/resources/trust-your-telemetry