📋 What was this drill?

Drill: No decoration: a landing page using ONLY typography, spacing, and alignment. No gradients, no illustrations, no decorative SVG, no glassmorphism. Target: looks designed, not empty.

Interpretation: Building a marketing landing for a fictional observability startup ('Tideline'). Testing whether the mono-as-decoration move (from the 2026-07-09 invoicing drill) generalizes to a marketing context, and whether the featured-card inversion pattern still reads as designed rather than templated.

v2.4·tail-based sampling is here·open beta

Distributed tracing that doesn't sample away the bug.

Tideline instruments every request end to end — across services, queues, and databases — and keeps the slow ones. p99 latency, dropped spans, and the one retry that timed out: all in one trace, no head sampling.

2.4ms
mean overhead per service, measured at 80k req/s
1.2M
spans ingested per second, single collector
<300ms
p99 query time over 30-day trace windows
40+
official SDKs, OTel-native, drop-in for most stacks
01 / 06 — The problem

Head sampling was built for storage budgets, not for finding bugs.

Most tracing systems decide what to keep at the edge of your network. The first service in a request rolls a dice — keep one in a hundred, drop the rest. The dropped spans are gone forever, including the ones where the bug lives.

This is fine when everything is healthy. It is catastrophic when it isn't. The requests you actually want — the slow ones, the failing ones, the ones that triggered a pager at 3am — are statistically the rarest traces in your traffic. 1% head sampling keeps the 99th percentile bug roughly 1% of the time.

Tideline inverts the decision. Every span is buffered through the collector. The trace is evaluated whole, then kept or dropped based on what actually happened — latency, error, a specific attribute, or a query you write at investigation time. You see the trace you came looking for, not the one the sampler happened to let through.

02 / 06 — How it works

Three stages, no sampling until the trace is complete.

Each stage is independently scalable and stateless except the buffer, which is tunable to your retention budget.

01/ 03

Instrument at the edge

OTel-native SDKs wrap your HTTP handlers, DB drivers, and queue consumers. Auto-instrumentation for 40+ frameworks. No manual span code to ship a first trace.

02/ 03

Buffer the whole trace

The collector holds spans in a sliding window keyed by trace ID. A trace isn't evaluated until its root span closes or the window expires — so the decision sees the full picture.

03/ 03

Keep what matters

Rules decide retention: keep errors, keep p99, keep traces touching a flagged deployment. Everything else drops. Storage cost stays flat; signal density goes up.

03 / 06 — Retention, in code

A retention policy is a config file, not a sales call.

Policies are evaluated in order. First match wins. Ship them with your service, version them in git, roll back in seconds.

# tideline.yaml — keep what your on-call needs
policies:
  - name: always-keep-errors
    keep: 100%
    when: status = error

  - name: keep-slow-tails
    keep: 100%
    when: duration > p99(service)

  - name: flagged-deploys
    keep: 100%
    when: deployment.tid = "d_8f3a"

  - name: baseline-traffic
    keep: 1%
    when: true   # everything else
→ evaluates in <4µs per trace · hot-reloaded on save
04 / 06 — In production

Numbers from teams running Tideline at scale.

71%
median reduction in mean time-to-detect for latency regressions, across 340 engineering teams.
→ internal cohort, Q1 2026
4hr
average cold-trace retrieval time for a 30-day-old incident — down from "not retrievable" under head sampling.
→ Northwind, case study
$0.12
per million spans retained, after policy. Comparable head-sampled storage ran $0.41 for 10% of the signal.
→ usage report, 90-day window
05 / 06 — Pricing

Priced by retained spans, not by hope.

You keep fewer spans because the policy is smart. Your bill reflects that.

Hobby
$0
For side projects and evaluation.
  • 5M retained spans / month
  • 7-day trace retention
  • Single project
  • Community support
Start free →
Enterprise
Custom
For high-throughput & compliance.
  • Unlimited retained spans
  • 1-year retention, configurable
  • Self-hosted collector option
  • SOC 2 · HIPAA · on-prem
  • Dedicated solutions engineer
Talk to us →
06 / 06 — Questions

The three questions every team asks first.

Doesn't buffering every trace cost a fortune in memory?
The collector buffers spans, not full traces, keyed by trace ID in a fixed-size ring. Default window is 8 seconds — enough for 99.97% of traces to complete. Memory footprint is bounded and tunable via buffer.window. Most teams run the collector at 1–2GB resident.
We already use OpenTelemetry. Do we rip it out?
No. Tideline is OTLP-native on the wire. Point your existing collectors at a Tideline endpoint and you're ingesting. The SDKs are the upstream OTel SDKs with a bundled exporter — no fork, no vendor lock-in at the instrumentation layer.
How is this different from just lowering my sample rate?
Lowering the rate keeps more of everything, including the 99% of traffic that tells you nothing. Tideline keeps 100% of the traces that match a policy and drops the rest deterministically. Same storage budget, ~60× more of the traces you'd actually open during an incident.

The bug is in the trace you didn't keep.

Stop gambling on head sampling. Ship the SDK, write a policy, and see the request that broke production — the whole thing, every span, the first time you look.