Skip to content
AutoObserve
Design Partner

AUTOBSERVE FOR DEVELOPERS

Debug production without reconstructing the incident by hand.

AutoObserve brings changes, metrics, logs, traces and runtime dependencies into an evidence-driven investigation so you can understand what changed, where the failure started and what most likely explains it.

Failure → Tools → Align → HypothesisFailure → Investigation → Evidence → Explanation → Inspect

See Production Debugging ↓Become a Design PartnerSee this perspective on Solutions →

PRODUCTION DEBUGGING TODAY

The telemetry exists. The investigation is fragmented.

CHECKOUT IS FAILING

Where do I start?

  • METRICS

    latency?

  • LOGS

    exceptions?

  • TRACES

    failed path?

  • DEPLOYMENTS
  • DEPENDENCIES

Developer

  1. Align timestamps
  2. Form hypothesis
  3. Test again

Specialised telemetry systems solve specialised problems. Production failures rarely respect those boundaries.

01 / START

Start with the thing that's actually broken.

NEW INVESTIGATION

SERVICE
checkout-api
PROBLEM
Error rate increased
ENVIRONMENT
Production
WINDOW
Last 30 minutes

Teaching UI — product entry ships with OSS

Or start from context you already have

  • Incident
  • Service
  • Trace
  • Log
  • Anomaly
  • Deployment
  • Ask a question

Move from telemetry navigation to hypothesis-driven debugging.

Traditional

"Checkout is failing."

  1. Where is the data?
  2. Which tool?
  3. Which query?
  4. Which service?
  5. Correlate manually

AutoObserve

"Checkout is failing."

  1. What changed?
  2. Where did it fail?
  3. What evidence supports that?
  4. What explanations fit?
  5. What contradicts them?
  6. Current explanation

02 / RECONSTRUCT

See what changed before production behaviour changed.

Recent changes · Deployment

  1. 1. 14:30:00

    DEPLOYMENT

    v2.14.7

    checkout-api deployed

  2. 2. 14:31:23

    ERROR RATE

    Errors ↑

    Degradation begins

  3. 3. 14:31:24

    NEW EXCEPTION

    PricingRuleException

    First observed

  4. 4. 14:31:31

    FAILED TRACES

    First divergence

    Inside checkout-api

Event sequence: 14:30:00 v2.14.7 → 14:31:23 Errors ↑ → 14:31:24 PricingRuleException → 14:31:31 First divergence

03 / FOLLOW THE EVIDENCE

One production question can cross every telemetry signal.

Did checkout behaviour change after v2.14.7?

EVIDENCE NEEDED

  • METRICS

    Did latency increase?

  • LOGS

    Did a new error appear?

  • TRACES

    Where do failed requests diverge?

  • SUPPORTING

    Evidence · Metric

    Checkout latency

    strong

    Baseline 241 ms · Observed 684 ms

    Observed
    684 ms
    Baseline
    241 ms
    Deviation
    +184% vs baseline
    Source
    Metrics
    Time
    14:31:00

  • SUPPORTING

    Evidence · Log

    Error signature

    strong

    First observed at 14:31:24 · LogQL

    Observed
    Connection acquisition timeout
    Source
    Logs
    Time
    14:32:11

  • SUPPORTING

    Evidence · Trace

    Failed traces

    strong

    Failed spans +312%

    Observed
    checkout → payment
    Source
    Traces
    Time
    14:31:31

RUNTIME CONTEXT

Is my service the cause, a victim, or simply nearby?

Question

What could be affected?

Direct vs indirect blast radius from Checkout

Blast origin

Checkout

Degraded · v2.14.7 · ORIGIN

Downstream

  • Inventory
  • PaymentDIRECT
  • OrdersDIRECT

Phase: BLAST. What could be affected? Direct vs indirect blast radius from Checkout Selected entity: Checkout. Upstream dependents: Web. Direct dependencies: Inventory, Payment, Orders. Incident state: Checkout: Degraded (ORIGIN); Payment: Impacted (DIRECT); Orders: Impacted (DIRECT); Stripe: Unknown (INDIRECT).

Explore Topology →

04 / TEST EXPLANATIONS

Don't stop at correlation. Test competing explanations.

Observation, evidence, hypothesis and current explanation stay distinct—uncertainty stays visible.

  • HYPOTHESIS 01

    checkout-api v2.14.7 introduced a regression.

    STRONGLY SUPPORTED

    • Supporting: Degradation followed deployment
    • Supporting: New exception appeared
    • Supporting: Failed traces originate here
    • Supporting: Downstream degradation followed
    • Contradicting: No infrastructure saturation

  • HYPOTHESIS 02

    payment-api caused checkout failures

    WEAK

    • Supporting: Payment latency increased
    • Contradicting: Checkout failed first
    • Contradicting: Payment degraded later

  • HYPOTHESIS 03

    Database saturation

    REJECTED

    • Contradicting: CPU normal
    • Contradicting: Query latency normal
    • Contradicting: Connections normal

PRODUCTION DEBUGGING EXPLORER

Timeline, explanations and evidence in one investigation.

A deterministic replay of the canonical checkout incident—select an event, explanation, or evidence item to see how they connect.

PRODUCTION DEBUGGING EXPLORER

checkout-api · Production · 14:31

Why did checkout failures increase after 14:31?

Selected · 14:30:00 · Deploy v2.14.7

RUNTIME PATH

frontend → checkout-api → payment-api → payment-db · + order-api

checkout-api is the likely origin — payment and orders degrade downstream

05 / GO DEEPER

When you need the raw evidence, it's still there.

AutoObserve can do the repetitive work without demanding blind trust.

Depth 1 / 4: EXPLANATION

Automate the repetitive work. Keep the engineering judgement.

AutoObserve handles

  • Gather evidence
  • Align timelines
  • Identify relevant changes
  • Explore dependencies
  • Generate queries
  • Compare hypotheses
  • Surface contradictions

You retain

  • Inspect evidence
  • Open raw telemetry
  • Modify queries
  • Reject explanations
  • Add context
  • Explore alternatives
  • Start a different investigation

Automation should increase engineering leverage, not remove engineering agency.

CODE MEETS PRODUCTION

Your repository isn't the production system.

Code tells you what the service was designed to do. Production evidence tells you what the distributed system actually did.

DEVELOPMENT

checkout-api/

  • ├── handler/
  • ├── pricing/
  • ├── payment/
  • ├── orders/
  • ├── config/

deploy

PRODUCTION

  • frontend
  • checkout-api v2.14.7
  • payment
  • orders
  • inventory
  • external-provider
  • Runtime changes
  • Telemetry
  • Dependency behaviour
  • Failure propagation

BUILT AROUND YOUR TELEMETRY

Use the production signals you already generate.

AutoObserve is OpenTelemetry-native and designed to coexist with the collectors and backends you already run—not replace them.

  1. 1. APPLICATIONS

  2. 2. OpenTelemetry

  3. 3. Metrics · Logs · Traces

  4. 4. Existing telemetry backends

  5. 5. AutoObserve

  6. 6. Investigation

Works alongside — not a replacement

  • Prometheus
  • Loki
  • Tempo / Jaeger
  • ClickHouse
  • Kubernetes

  • OpenTelemetry pipelines

    Subscribe to the OTel collector / gateway pipelines you already operate.

  • Existing backends

    Generated PromQL, LogQL, and TraceQL run against the stores you already trust.

DEVELOPER FAQ

Do I need to learn another query language?

No. Start from the production question and investigation. Drop to PromQL, LogQL, or TraceQL when you need more control—no proprietary query language required.

START HIGH

  1. Production question
  2. Investigation
  3. Evidence

NEED MORE CONTROL?

  1. Evidence
  2. Generated query
  3. PromQL / LogQL / TraceQL
  4. Raw result