Streamwake + AWS MediaTailor.
Don't replace AWS MediaTailor — we correlate its SSAI signals against the CDN + AWS-side control-plane signals and surface server-side ad-insertion failures on the same investigation timeline.
Don't replace AWS MediaTailor — we read the adBeaconDrop / sessionInit / scte35LateResponse events MediaTailor's operator-managed relay pushes into Streamwake, correlate them against the CloudFront + CloudWatch + AWS MediaLive + Bitmovin + Conviva pair the adjacent +X pages already name, and surface ad-decision-system outages as ranked candidates on the same investigation timeline. An ad-tracking outage that started at the ad-decision system and a chart that started at the CDN edge land on the same frame — never collapsed into one symptom.
AWS MediaTailor server-side ad insertion — ad-beacon drops / session-init failures / late scte-35 responses. Streamwake doesn't replace AWS MediaTailor— we correlate its signals and drive remediation on the anomalies it already surfaces.
What AWS MediaTailor owns. What Streamwake runs on top.
Honest framing of the surface the vendor owns and the surface Streamwake runs on top of it. Both layers run together in production — same signal bus, different obligations.
Server-side ad insertion (SSAI) at the CDN edge
SSAI telemetry surface (per-configuration, per-session)
Detect → Classify → Fix on the ad-decision-system side
SSA cross-vendor anomaly alignment
An incident closed
before your viewers notice.
Four steps from a AWS MediaTailoranomaly to a closed incident with a typed postmortem. Read top to bottom — the loop is closed end to end.
- 1
Operator wires an EventBridge / Lambda relay → our `/api/v1/mediatailor-events/inbound`
MediaTailor does not natively push a webhook — the operator builds (or copies) a thin EventBridge / Lambda relay that reads MediaTailor's per-configuration adBeaconDrop / sessionInit / scte35LateResponse events off the AWS-side control plane and POSTs them one record at a time to the per-source Streamwake inbound URL. The inbound route resolves the tenant from the shared per-source `routerToken` — no cross-tenant leak. A 'Send test event' button on the setup island synthesizes a canonical fixture envelope end-to-end.
- 2
Normalize the three SSAI failure kinds into the investigation timeline
Each MediaTailor adBeaconDrop / sessionInit / scte35LateResponse event gets parsed by `parseMediaTailorEnvelope`, persisted to `MediaTailorEvent` (deduped on `(userId, sourceId, upstreamId)`), and stamped with the per-source `region` for the correlator's region-anchor scoring. Session id + adAvailId + the latency / dropCount / status payload ride through unchanged so the InvestigationCorrelationsPanel can render the row against the merged CloudFront + CloudWatch + AWS MediaLive timeline.
- 3
Correlate against CloudFront + CloudWatch + align with the viewer's QoE side
The correlator joins each captured MediaTailor event against the closest pull-side CloudwatchEvidence + Bitmovin + Conviva row for the same incident, scores each by a small typed heuristic (`ssai_ad_beacon_drop` ≥ threshold → +30; `ssai_scte35_late_response` above threshold → +35; `ssai_session_init_failure` → +40; ±30s of CloudWatch → +20; region-matches the source row → +10), and persists a MediaTailorCandidate row. SSAI failures stay distinct from upstream CDN or viewer-side regressions on the same incident frame.
- 4
Pair with the existing Bitmovin + Conviva QoE + AWS MediaLive control-plane lanes
MediaTailor adds the ad-decision-system dimension alongside (rather than replacing) the Bitmovin impression-scoped + Conviva session-scoped viewer-side lanes + the AWS MediaLive channel-state control-plane lane. The InvestigationCorrelationsPanel on /app/incidents/[id] renders MediaTailor candidate rows with the same typed confidence + reason chip the existing pairs already carry, so the operator sees the SSAI signal AND a paired viewer-side rebuffer cluster on the same frame. A late-SCTE-35 ad-decision stall + a viewer-side rebuffering surge + a CloudFront cache miss + a CloudWatch alarm becomes one typed classification + one ad-decision-system remediation.
Four failure modes AWS MediaTailor alerts alone miss.
Each one is something the AWS MediaTailorsignal exposes but the agent loop names and acts on — so a chart becomes a closed incident rather than a triage queue.
Ssai_ad_beacon_drop (ad-tracking Outage)
A MediaTailor adBeaconDrop event lands with dropCount above the per-source threshold (default 2) — the most likely cause is an ad-decision-system stall that missed tracking beacons across the expected tracking window. MediaTailor surfaces the beacon-side drop on the AWS console; Streamwake catches the dropCount-cluster on the same window, surfaces the `ssai_ad_beacon_drop` typed classification, and queues a paired ad-decision-system + manifest retune before the next ad break lands tracking-blind.
Ssai_session_init_failure (configuration Entitlement Outage)
A MediaTailor sessionInit event lands with status='failure' + a reasonCode (`NoEntitledAd` / `NoAvail` / `AdPodEmpty` / …) — the most likely cause is an SSAI configuration whose ad-pod is empty for the current session or whose entitlements don't line up. MediaTailor surfaces the configuration-level fail on the AWS console; Streamwake catches the configuration-cluster on the same window, surfaces the `ssai_session_init_failure` typed classification, and queues a paired configuration entitlement retune (ad-pod rebuild / entitlement refresh).
Ssai_scte35_late_response (ad-decision-system Stall)
A MediaTailor scte35LateResponse event lands with latencyMs above the per-source threshold (default 8000ms) — the most likely cause is a downstream ad-decision system that stalled on the SCTE-35 response. MediaTailor surfaces the late-response on the AWS console; Streamwake catches the latency-cluster on the same window, surfaces the `ssai_scte35_late_response` typed classification, and queues a paired ad-decision-system stall remediation before the next ad break lands ad-blind.
SCTE-35 Ad-marker Loss Storm (live-to-VOD Handoff Pairing)
A MediaTailor scte35LateResponse event lands paired with a late-session SCTE-35 stall above threshold during a live-to-VOD hand-off, AND the AWS MediaLive channel-state stream shows the corresponding upstream splice fail — the most likely cause is an SCTE-35 marker loss across the ingest handoff paired with a downstream ad-decision-system stall. Streamwake joins them against the /incident-lab/scte-35-ad-marker-loss-live-to-vod pattern + the Bitmovin rebuffering ratio on the same window as a single typed classification `ssai_scte35_storm_with_live_to_vod_handoff`, and surfaces the paired ad-decision system + manifest retune.
Connect AWS MediaTailor to your investigation timeline free.
Next to AWS MediaTailor.
Wire your operator-managed AWS MediaTailor relay — paste the per-source `routerToken`, run /stream-check to validate the live-end checks on the live feed (manifest, segments, bitrate ladder, CDN response, playback errors) in under a minute. No login. Pair it with the Book-a-demo block below for a guided walkthrough of the SSAI correlation lane on top of your existing Bitmovin + CloudFront + CloudWatch + AWS MediaLive + Conviva pairing.
SCTE-35 late-response storm paired against ad-decision fault + viewer-side qoe drop.
mediatailor.scte35.late_response fired 113 events in 90s with latencyMs=14_200 on topgear-pre-roll in us-east-1— paired against AWS MediaLive medialive.channelState flipping to `PIPELINE_ERROR` on the same ad-decision config.
The agent classified the joint MediaTailor-SSAI-side + AWS-MediaLive-origin-side signal as ssai_scte35_late_response_with_mediatailor_config_pipeline_error at 92% confidence, emitted a paired MediaTailor config rollback + a paired encoder pipeline resync, and emitted the remediation back as streamwake.mediatailor.ssai_scte35_late_response.remediation.applied onto the MediaTailor dashboard — so the same console that flagged the SCTE-35 marker storm re-renders the loop-closure metric the moment the fix lands.
Direct mapping to the Streamwake detect → classify → fix loop on the MediaTailor-SSAI → CloudWatch + AWS MediaLive signal bus — the same `scte35LateResponse=14_200ms` storm AND the matching AWS MediaLive channel-state `PIPELINE_ERROR` flip on the same MediaTailor config the page pins to are the signals the InvestigationCorrelationsPanel renders under the ranked hypothesis list on /app/incidents/[id], and the typed remediation lands back into AWS MediaTailor as a new metric the operator can immediately re-scrape or alert on.
Configure the source,
ship your first SSAI event, light the inbound.
The in-page setup island mounts the push-side MediaTailorSourceCard and a companion inbound webhook card. Configure the source first, copy the per-tenant routerToken, wire your operator-managed SSAI relay to POST to /api/v1/mediatailor-events/inbound?token=<routerToken>, and hit Send test event to verify the inbound lands on the same investigation timeline the merged panel reads.
Wire your operator-managed AWS MediaTailor relay so a vendor-side HTTP transport POSTs one record per adBeaconDrop / sessionInit / scte35LateResponse event to the Streamwake endpoint. The webhook shares the per-source routerToken, so the inbound route resolves your tenant from ?token=<routerToken> first and drops the SSAI event onto the same investigation timeline the merged panel reads.
(empty)(not configured)(empty)(unset)(no events yet)routerToken from that row.curl -X POST '?token=<routerToken>' \
-H 'content-type: application/json' \
-d '{"as":"__test_fixture__","sourceToken":"<routerToken>","envelope":{"kind":"scte35LateResponse","upstreamId":"smoke-1","eventTime":"2026-08-24T05:27:55.786Z","sessionId":"smoke-session-1","adAvailId":"smoke-avail-1","expectedPtsMs":3600000,"actualPtsMs":3614200,"latencyMs":14200,"region":"us-east-1"}}'Recent SSAI events
Loading…
What an operator needs on the AWS side before the relay can fan in.
What an operator needs in the AWS account before the operator-managed MediaTailor relay can start pushing adBeaconDrop / sessionInit / scte35LateResponse events to Streamwake. The list matches the source card on /integrations/mediatailor — the labels, the region, and the relay transport stay in lockstep with what is wired on the relay side.
MediaTailor configuration + AWS region
The recommended posture is one MediaTailor configuration per AWS region — the free-form accountName + required regionon the source card are the labels Streamwake renders inline. Pick labels an operator on the same Streamwake tenant can tell apart from a second MediaTailor configuration so the +MediaTailor island doesn't collide with a future second-region install.
MediaTailor ingest is push-only via the relay — the source row carries NO credentials. The only secret-bearing surface is the per-source routerToken (24 bytes hex, minted on first save), which the operator copies into the relay URL — not a credential pair, not a shared admin cookie.
Operator-managed relay + per-source router token
The relay pushes one record per SSAI event with the typed { as, sourceToken, envelope } JSON shape. The envelope.kind discriminator narrows per-kind so the inbound route + correlator reason a typed signal without re-parsing. The route never verifies HMAC for v1 — the seam that scopes the relay to the right Streamwake tenant is the per-source routerToken keyed onto ?token=<routerToken>.
The webhookSecret column is typed but unused on first pass — a future EventBridge-bridged relay that DOES issue per-source HMAC plug in without a schema change. The inbound route resolves tenant purely by routerToken for v1.
The AWS MediaTailor discriminator kinds the inbound route + correlator read. Every kind on this list is the one a relay pushes through the typed envelope envelope — a kind on this list is the one the InvestigationCorrelationsPanel + the recent-events log render inline with the typed headline SSAI column.
| Kind | Covers |
|---|---|
| adBeaconDrop | A tracking/beacon event drop within the expected delivery window. Probe: `dropCount >= 2` (the contract-layer default threshold; tunable on the source card) within `expectedWindowMs`. Surfaces as `ssai_ad_beacon_drop` (score +30). A single dropped beacon is normal; ≥2 across the session indicates a session-level ad-tracking outage that the next ad break will inherit. |
| sessionInit | A MediaTailor `session.create()` outcome carrying `status: 'success' | 'failure'`. Probe: `status === 'failure'`. Surfaces as `ssai_session_init_failure` (score +40) — the highest weight in the heuristic set, because a session.init failure isolates the entire viewing session, not a single ad break. The correlator pairs it against the AWS MediaLive channel-state stream so the player-side retry is the typed remediation, not a CDN retune that wouldn't have helped. |
| scte35LateResponse | A SCTE-35 marker arrived late downstream. Probe: `actualPtsMs > expectedPtsMs` OR `latencyMs > 8000` (the contract-layer default; tunable on the source card). Surfaces as `ssai_scte35_late_response` (score +35). Either signal alone is enough to qualify — late PTS above the pre-calculated reference AND raw latency above the threshold both indicate a downstream ad-decision system stall. |
Five steps from a blank source card
to a verified SSAI event landing on the timeline.
The wire sequence the operator runs to attach AWS MediaTailor to Streamwake as a server-side ad-insertion source. Matches the order the source card's expanded form walks through — configuration, region, thresholds, relay URL, token mint, verify.
- 1
Configure the MediaTailor configuration
In your AWS account, pick the MediaTailor configuration + AWS region you want to mirror into Streamwake. The free-form `accountName` + required `region` on the source card are the labels Streamwake renders inline — pick a region the MediaTailor configuration already lives in (two configs in different regions cannot be told apart without this hint).
- 2
Set the correlator thresholds (optional)
Streamwake's correlator applies a small typed heuristic to the inbound SSAI events. The contract-layer defaults — adBeaconDrop threshold 2 (≥2 drops in the expected window) and scte35LatencyThresholdMs 8000 (latency above 8s indicates a downstream ad-decision stall) — ship automatically. Override either on the source card whenever the operator tunes the heuristic: it's typed at the contract layer and stored as a column on the source row, so a future correlator pass reads the override without code.
- 3
Wire the operator-managed MediaTailor relay
MediaTailor itself does NOT natively push events to a webhook. Configure your in-house EventBridge / Lambda relay to shovel MediaTailor events to the Streamwake inbound URL — one record per `adBeaconDrop` / `sessionInit` / `scte35LateResponse`. The relay POSTs with the typed `{ as, sourceToken, envelope }` JSON shape, where `envelope.kind` is the discriminator that narrows per-kind so the inbound route + correlator reason a typed signal without re-parsing.
- 4
Save the source + mint the router token
Save the source row on /integrations/mediatailor. The first save mints a per-source `routerToken` server-side (24 bytes hex) — copy the token into your relay URL as `?token=<routerToken>`. The relay gets scoped to the right Streamwake tenant; the inbound route resolves tenant purely by the `routerToken` for v1.
- 5
Hit Send test event + verify the inbound lands
Click `Send test event` on the setup card. The test-fixture route synthesizes a canonical `scte35LateResponse` event with `latencyMs=14_200` on the configured account + region and POSTs it through the same inbound pipeline a relay would land. The recent-events log on the same page lights the moment the inbound closes; the InvestigationCorrelationsPanel on /app/incidents/[id] surfaces the candidate the moment you run the correlation pass with a `mediaTailorCandidateCount === 0 → seed correlator` flow.
The operator-managed MediaTailor relay doesn't sign — the per-source routerToken keyed onto ?token=<routerToken> is the seam. The token is replaced only by deleting the source row + re-saving (the asset stays stable across re-renders — re-generating would break already-deployed relays that point at the old token). The future webhookSecret surface is reserved but unused on first pass.
What becomes available
once the SSAI events flow in.
The typed action set the correlator surfaces once the inbound closes and a MediaTailorEvent row lands. The four below are what the agent renders on the same incident detail — ranked hypothesis, MediaTailor-SSAI- correlated panel, cross-vendor alignment, and same-frame AWS-tier vs SSAI-layer pairing.
Ranked SSAI hypothesis + confidence
The agent joins the captured MediaTailor events against the CDN, encoder, and AWS-side signals on the same bus and ranks root cause with a typed confidence score. The classification slug — `ssai_ad_beacon_drop` vs `ssai_session_init_failure` vs `ssai_scte35_late_response` — is what ranks, never the raw SSAI numeric.
InvestigationCorrelationsPanel MediaTailor SSAI row
The InvestigationCorrelationsPanel under the existing HypothesisList on /app/incidents/[id] renders the captured MediaTailor candidate alongside the CloudWatch / CloudTrail / CloudFront / Bitmovin / Conviva rows. Every MediaTailor row carries the SSAI head (adBeacon drop count / sessionInit status / scte35 latencyMs) + the session id + the configuration name + the region + the typed anomaly class + the typed confidence score — same frame, same timeline, one ranked list.
Cross-vendor alignment ±30s of CloudWatch evidence
When a MediaTailor event capturedAt falls within ±30s of a CloudwatchEvidence row on the same incident, the InvestigationCorrelationsPanel surfaces the same `±Xs of CloudWatch evidence` chip every other watcher vendor carries — so a server-side ad-insertion fault that started at the SSAI tier and a chart that started at the AWS-side control plane never silently belong to one symptom.
Same-frame AWS-tier vs SSAI-layer pairing
On the incident close, the typed SSAI-side remediation fans out as `streamwake.mediatailor.<ssai_classification>.remediation.applied` onto the MediaTailor config the operator already polls — so the same dashboard panel that flags the SCTE-35 late-response storm renders the loop-closure metric the moment the fix lands. Operators can re-scrape it, alert on it, or fan it back into the CloudFront / CloudWatch / AWS MediaLive +X pairing without a retune.
Book a 20-minute walkthrough on your MediaTailor configuration.
We're happy to walk through how the per-event adBeaconDrop / sessionInit / scte35LateResponsediscriminator signals map onto your existing CloudFront + CloudWatch + AWS MediaLive pairing — and how the typed server-side classifications surface on the same investigation timeline the merged panel reads. Drop your details below and we'll follow up within 1 business day.