Your causal engine is only as good as its inputsGive it a real front-end source of truth
Agentic RCA and AI-SRE tools build a causal model from whatever telemetry they can read. Most synthetic monitors feed them a green dot and a latency number. Yorker feeds them a structured span with third-party attribution, a baseline-scored verdict on the completed event when a run silently degrades, and a W3C traceparent that becomes one trace with your backend the moment your services continue it.
# synthetics.check.run span. already in otel_traces
synthetics.check.name "Checkout Flow"
synthetics.check.type browser
synthetics.check.status failure
synthetics.location.name London, UK
synthetics.response_time_ms 9120
synthetics.third_party.count 12
synthetics.third_party.domains [cdn.tagmanager.net, ...]
synthetics.screenshot.url https://r2.yorkermonitoring.com/...
# W3C traceparent header the browser executor injected
# into the request. continues into your backend trace
traceparent 00-4bf92f35...-a3ce929d-01
# synthetics.check.failed log event. in otel_logs
synthetics.consecutive_failures 3
synthetics.suggested_next_steps [check upstream cdn, ...]
A new consumer changed the requirements
For twenty years synthetic monitoring had one consumer: a human looking at a dashboard. A new class of tool now reads that same telemetry. Agentic RCA, AI-SRE, and causal-analysis engines do not want a chart. They want structured signal they can correlate against deploys, infrastructure changes, and backend traces. Nobody in synthetics is building for that consumer. Yorker is.
The check runs and the signal is enriched
An HTTP or browser check executes from a global or private location. On browser checks the runner attributes third-party requests on the span. When a run succeeds, Yorker scores it against per-metric, per-location, per-hour baselines and attaches the anomaly verdict to the completed event, so a silent slowdown is flagged before it becomes an outage. What reaches your engine is pre-analyzed, not raw.
It lands in your backend as standard OTLP
Spans, metrics, and structured log events are emitted in parallel to your OTel backend. The synthetic check sits in the same store as your APM, logs, and infrastructure telemetry. No silo for an external engine to integrate against.
The causal engine correlates it
A W3C traceparent is injected into the check's HTTP requests. When your instrumented services continue that context, the synthetic run and the backend trace are one distributed trace, so the join key the engine needs is in the data instead of inferred from timestamps.
Signal a causal model can use
A causal engine reasons over edges: this change caused that symptom. Edges need attribution and a join key. Most synthetic data has neither. Here is what Yorker puts in your backend for it to read.
- A join key, already attachedW3C traceparent is injected into the browser check's HTTP requests. The synthetic run and your backend trace are the same trace, so the engine correlates on trace ID instead of guessing from timestamps.
- Third-party attribution on the spanBrowser checks emit synthetics.third_party.count, total_bytes, and the domain list as span attributes. When a failure is caused by someone else's CDN or tag, the blast-radius answer is in the data, not a manual investigation.
- Anomaly context on the completed eventWhen a successful run deviates from its baseline, synthetics.check.completed carries synthetics.is_anomalous, anomaly.deviation_sigma, and baseline_value. The engine reads a scored deviation for the silent slowdowns, the degradations that never trip a hard failure, not a raw number it has to baseline itself.
- Structured failure, not just a statussynthetics.check.failed carries consecutive_failures and suggested_next_steps. A flap and a sustained outage are distinguishable in the signal, which is exactly the distinction a causal model needs.
- Visual evidence by referencesynthetics.screenshot.url points at the exact frame, stored in R2. The engine, or the human reviewing its conclusion, pulls the evidence without leaving the backend.
- Conclusions, not a context-window dumpYorker emits an attributed summary span with anomaly-scored log events beside it, not hundreds of raw waterfall entries. The engine ingests a conclusion-bearing signal instead of spending its context budget re-deriving one.
traceparent (join key)in HTTP request headerssynthetics.check.statusotel_traces (span)synthetics.response_time_msotel_traces (span)synthetics.third_party.domainsotel_traces (span)synthetics.screenshot.urlotel_traces (span)synthetics.is_anomalousotel_logs (event)synthetics.anomaly.deviation_sigmaotel_logs (event)synthetics.consecutive_failuresotel_logs (event)synthetics.suggested_next_stepsotel_logs (event)Span attributes land in otel_traces; anomaly, SLO, and failure context land in otel_logs as structured events. A causal engine joins them on synthetics.run.id and trace ID.
Pre-correlated, not a firehose
An agentic RCA tool has a finite context budget. Feed it a raw network waterfall and it spends that budget reconstructing what happened. Yorker does the front-end analysis first: classify the requests, attribute the third parties, score the anomaly, attach the trace context. What reaches the engine is a compact, conclusion-bearing signal.
The result is sharper, cheaper reasoning. The engine correlates a scored summary against your deploys and infrastructure changes instead of parsing noise to find the one request that mattered.
# what most synthetics emit
187 raw network entries, no attribution
no anomaly score, no trace join key
engine must re-derive the conclusion
# what Yorker emits
# span (otel_traces)
synthetics.check.status failure
synthetics.third_party.domains [cdn.tagmanager.net]
# log event (otel_logs)
synthetics.is_anomalous true
synthetics.anomaly.deviation_sigma 3.4
# header on the request
traceparent 00-4bf92f35...-01
# one span, its events, one join key. conclusion included.
Unlike every other synthetic monitor
Other synthetic tools were built for a human reading a dashboard. The output is a chart and an alert. An agentic RCA engine reading that gets a status code and a latency number with no attribution and no join key.
Yorker was built so the signal is useful to a machine downstream. Third-party attribution on the browser-check span, a baseline-scored verdict on the completed event when a run degrades, and a W3C traceparent for trace continuation: all standard OTLP, in the same backend your causal engine already reads.
It works through your backend, not a proprietary integration. Yorker emits standard OTLP; any AI-SRE or causal-analysis tool that ingests your observability data inherits the front-end source of truth with zero coupling to Yorker.
Related Features
The full OTLP insight pack: what Yorker emits and where each signal lands in your backend.
Playwright checks with third-party dependency attribution and filmstrip evidence.
Cross-monitor correlation and alert triage with full OTel context.
Close your observability blind spot
Free tier includes 10,000 HTTP checks and 1,500 browser checks per month. No credit card required.
npx yorker init