Streamwake + Fastly.
Don't replace Fastly — we correlate its edge-compute bundle, VCL compilation, instant-purge, and real-time log signals and drive remediation on the edge.
Don't replace Fastly — we correlate the edge-compute bundle lifecycle, VCL compilation drift, instant-purge lag, and real-time log signals Fastly already surfaces, and drive remediation on the edge — VCL drift, edge-compute staleness, purge-window drift, and RT-log stream gaps before they cascade.
Fastly edge cdn + compute@edge + vcl + instant purge. Streamwake doesn't replace Fastly— we correlate its signals and drive remediation on the anomalies it already surfaces.
What Fastly 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.
Edge delivery + caching
VCL + Compute@Edge
Detect → Classify → Fix
Postmortems
An incident closed
before your viewers notice.
Four steps from a Fastlyanomaly to a closed incident with a typed postmortem. Read top to bottom — the loop is closed end to end.
- 1
Ingest Fastly telemetry
VCL compilation events, Compute@Edge bundle publish + activate + pin transitions, real-time log streams, instant-purge API responses, and per-POP request / 5xx / purge logs land on the Streamwake signal bus via a single REST POST.
- 2
Correlate and rank
The agent joins Fastly signals against CDN, encoder, and DRM signals on the same bus, then ranks root cause with a typed confidence score (vcl_compilation_skew vs edge_compute_bundle_staleness vs instant_purge_lag vs rt_log_saturation).
- 3
Recommend or run a fix
The agent picks the smallest safe remediation — re-issue VCL, republish a stale Compute@Edge bundle, refire an instant purge with the corrected key, fail over the RT-log endpoint — and verifies recovery before closing out.
- 4
Write the postmortem
A structured incident writeup — what happened, what was tried, what changed — lands in the team's inbox the moment the incident resolves.
Four failure modes Fastly alerts alone miss.
Each one is something the Fastlysignal exposes but the agent loop names and acts on — so a chart becomes a closed incident rather than a triage queue.
Vcl Compilation Skew
VCL compilation drift between staging and production — a snippet edit or a custom VCL change compiled clean in staging but failed silently on the prod service, so the staging-compiled bundle is live while the prod-compiled bundle is stale (or vice versa). Fastly shows the diff in the VCL history; Streamwake catches the staging-vs-prod compilation skew the moment the per-POP logs diverge and pins which snippet or behavior caused it.
Compute Edge Bundle Staleness
A Compute@Edge Wasm bundle pinned to an old version after publish — the new bundle activated but the edge service kept routing to the pinned version because the version-pin API never propagated to every POP. Fastly logs the publish + activate; Streamwake catches the bundle-vs-pin skew on the same bus and surfaces a typed next-action (re-issue the pin, force a version reset, warm the affected POPs).
Instant Purge Lag
An instant-purge API call accepted at the Fastly control plane, but the POPs lag returning stale bytes for a window after the purge — manifest pulls 200, segments 200, but content reflects the previous golden version. Fastly surfaces the purge-queue depth; Streamwake reads the purge-window / per-POP log divergence on the same signal and refires the purge with the corrected cache-key before viewers fetch stale content.
Real Time Log Stream Gap
A Fastly real-time log endpoint saturates (TLS endpoint backpressure, downstream shipper slow, or receiver-side queue overflow) — the RT-log stream goes quiet for a window while the rest of the Fastly signal bus keeps firing. Streamwake catches the RT-log arrival gap the moment the stream stalls and either fails over to a secondary endpoint or queues a retry so the signal trail stays continuous.
Monitor your Fastly edge free.
Next to Fastly.
Paste your Fastly playback URL — /stream-check runs the same five checks (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 VCL / Compute@Edge / instant-purge probe lane.
VCL compilation skew caught between staging and production.
edge.vcl.compilation_diff_lines report surface drifted to 2,847 s vs 184 sbaseline — a 93% overshoot on the primetime edge hostname, observed after a custom VCL snippet edit that compiled clean in staging but never propagated to the prod service, leaving the staging-compiled VCL active while the prod compile sat stale.
The agent classified it as fastly_vcl_compilation_skew at 87% confidence, emitted a re-issue of the VCL bundle + an instant purge with the corrected cache-key, and the edge-config drift cleared within 9 minutes.
Direct mapping to the Streamwake edge-compute probe lane — every signal that fired the VCL compilation skew hypothesis is the same signal a Fastly Compute@Edge bundle staleness or an instant-purge lag pushes onto the bus. The agent that closed the primetime incident is the same one that catches a Wasm bundle pinned to an old version after publish and a RT-log endpoint saturation the moment the stream trail goes quiet.
Book a 20-minute walkthrough on your Fastly edge + Compute@Edge setup.
We're happy to walk through how the VCL-compilation-skew, Compute@Edge-bundle- staleness, instant-purge-lag, and RT-log-stream-gap probes map onto your existing Fastly + Compute@Edge setup. Drop your details below and we'll follow up within 1 business day.