Incident rehearsal for production

Rehearse your next incident before it happens.

Aftershock turns your real production traffic into load scenarios, replays past incidents against staging, and shows whether your alerts would have caught them.

Become a design partner See how replay works

Now inviting 3–5 SRE teams to shape the product as design partners.

checkout-cascade · replay replaying
Production, Mar 14 incident window Aftershock replay
0arrival-curve match
0req/s at peak
1 of 3alerts fired in time
Illustrative example

The problem

Most teams find their limits during an incident.

Load tests don't look like production

Scripted tests hit a few endpoints at a steady rate. Real surges are a mix of user journeys, retries and spikes, and that mix is what breaks things.

Traces tell only part of the story

Production tracing is usually sampled at 1–5%. Rare journeys and exact incident-time rates fall through the gaps.

Nobody knows if the alerts would fire

Dashboards and alerts get tuned after the last incident. Until the next one, nobody knows whether monitoring would catch it in time.

How it works

From production traffic to a release gate, in four steps.

  1. 1

    Mine

    Point the miner at your edge logs (nginx first) or traces. It finds user journeys, arrival curves and the request mix, on your machine.

  2. 2

    Replay

    A precise load engine replays the scenario from an agent inside your network, or from our hosted zones for verified public endpoints.

  3. 3

    Observe

    Every request carries a trace context and run ID. Aftershock reads your Prometheus, Elastic, OpenSearch, Tempo or Jaeger and shows which service the latency came from.

  4. 4

    Gate

    Your pipeline fails the release when SLOs break or it regresses against the last good run. Multi-hour soaks run without holding a CI runner.

Incident replay

Turn last quarter's incident into a test you run on every release.

Pick the window when things went wrong. Aftershock rebuilds the traffic that caused it, replays it against staging, and checks what your monitoring saw.

access.log · Mar 14, 09:30–10:30runs on your machine

The miner reads every request in the incident window, not a 1% sample. Session keys are hashed on the spot, and raw logs never leave your machine.

Illustrative example

Observability coverage

Would we have caught it?

Every replay doubles as a test of your monitoring. Aftershock checks your Alertmanager and Elastic alerting during the run and tells you which alerts fired, how fast, and which never fired at all.

  • Find coverage gaps before customers do
  • Measure time-to-alert on a real incident shape
  • Re-run after every alerting change to prove it works
replay timeline · 0–20 min1 of 3 in time
0m5m10m15m20m SLO: 1% errors p99 latency · fired 3m 12s budget burn · fired 11m billing queue depth · never fired
Illustrative example
checkout · CPU per 1k req/s12 releases · 12 months
DecFebAprJunAugOctNov new node type Jul release · +21% CPU
  • checkoutDatadog
  • searchPrometheus
  • catalogOpenSearch
  • billingmemory: no data
Illustrative example

Release ledger

One performance record across every tool and every release.

Your teams keep metrics in Grafana, Datadog and OpenSearch, and a release report means screenshots from all three. Aftershock keeps a summary of every run, for every critical component, for years.

  • The signals that cause outages. CPU, throttling, memory growth, pod scaling, restarts, node CPU, latency and errors, for each component.
  • From the tools teams already use. Prometheus and Grafana stacks, Elastic and OpenSearch first; Datadog on the roadmap. Nobody has to switch.
  • Gaps are findings. A component with no memory data in any tool shows up in the report, not in the postmortem.
  • Any release against any other, a year back, with environment changes marked instead of hidden.

Enterprise readiness

Ready for enterprise customers, with evidence to show for it.

When a large customer signs, they bring traffic you haven't seen and a security team with questions. Aftershock gives SRE teams a way to prove readiness instead of promising it.

Prove peak capacity before onboarding

Model the new customer's expected traffic, replay it against staging at 2× or 5×, and share a report that shows where the limits are.

A report leadership can read

One page per release: critical components at risk, regressions this quarter and headroom against the forecast peak, with HTML and PDF exports.

Evidence for availability reviews

Scheduled capacity tests leave a dated record of what was tested and what passed. Useful for SOC 2 availability controls and customer security questionnaires.

Rehearse the runbook, not just the system

Replay an incident in staging and run the on-call drill against it. Find out whether the pages, dashboards and runbook steps hold up.

Security and data

Your data stays in your network.

Aftershock is built to pass your security review, because it holds almost nothing worth taking.

  • No inbound connections. The agent dials out over gRPC with mutual TLS.
  • Aggregates only. We store scenarios, histograms, run metadata and metric summaries. Never raw traces, logs, payloads or personal data.
  • Mining and metric queries run on your side, with read-only credentials that never leave your cluster.
  • Hosted load only to verified domains, with rate caps, a kill switch and a dead-man's switch.
  • Signed releases. Agent images and charts are signed and ship with an SBOM.
  • SOC 2-ready practices from day one: SSO and MFA, least privilege, audit logging.
Your network Staging system aftershock-agent Elastic · TempoPrometheus load queries Aftershock control plane outbound mTLS aggregates only

The engine

Load that behaves like users, measured honestly.

Open workload model

Requests arrive at the rate production saw, even when your system slows down. Closed-loop tools quietly back off; real users don't.

Coordinated-omission correction

Latency is measured from when each request should have been sent, so a stalled server can't hide its own slowness.

HDR histograms

Full-resolution latency distributions, merged across agents, so p99 and p99.9 mean what they say.

HTTP/1.1, HTTP/2 and gRPC

Multi-step journeys with cookies, auth, extracted values and unique synthetic data.

Trace context on every request

W3C traceparent and the run ID ride along, so your telemetry can be filtered to exactly our traffic.

Runs locally for free

One binary runs scenarios on your laptop or in CI. The cloud adds coordination, history and reports.

Works with nginx logsPrometheusGrafanaElasticOpenSearchTempoJaegerOpenTelemetryGitHub ActionsGitLab CIKubernetes (Helm)Datadog · plannedNew Relic · plannedJenkins · planned

Design partners

Help shape Aftershock.

We're looking for a small group of SRE teams to build with on real systems before general availability. If incidents keep surprising your team, let's talk.

What you get

  • Free use during the program
  • A replay of one of your real incidents
  • A direct line to the founder
  • Your incidents shape the roadmap

What we ask

  • Run it against a staging system
  • A 30-minute check-in every two weeks
  • Honest feedback on what's missing

Aftershock is founded by Ruben Quinones, a former SRE performance engineering leader who has spent years running load tests, capacity reviews and incident retros on large platforms.

Start with your last incident

Tell us what happened, how you load test today and what you wish you'd known beforehand. The founder reads and answers every message.

We use what you send only to reply to you, and delete it after two years. No tracking, no mailing lists. Privacy notice

Questions SRE leads ask

Is this a load-testing tool or an observability tool?

A load-testing tool that starts from your production traffic and ends with your observability. It generates the load and reads your existing monitoring; it doesn't replace either.

Do we need full tracing?

No. Edge logs (nginx first, more formats to follow) are enough to rebuild journeys and traffic shape. Traces add detail if you keep enough of them.

Does any of our data leave our network?

Only aggregates: scenarios, latency histograms, run metadata, per-service summaries and metric summaries. Raw logs, traces, metrics, payloads and personal data stay with you.

Our teams use different observability tools. Does that matter?

No. Each component is read from whichever tool its team uses, and the report puts them side by side. Prometheus-compatible stacks, Elastic and OpenSearch come first; Datadog is on the roadmap.

How is this different from k6, Gatling or Locust?

Those are good at generating load from scripts you write. Aftershock builds the scenario from your real traffic, replays incidents with their exact shape, checks whether your alerts would have caught them, and keeps the results by release.

Can it run against production?

It's designed for staging first. Hosted load zones only target domains you've verified, under rate caps, with a kill switch, and during the design-partner program every hosted run is approved by us.

What does it cost?

Nothing during the design-partner program. Pricing comes later and will be shaped with our partners.