This change hurt production
Which change, which symptom, which users and services. Each statement links to the query and data behind it. A recovery step comes with it.
Change safety
Did that change
hurt production?
Within minutes of every change, Epok tells you if it hurt production and what to do to recover, which is usually to roll back that change. It shows the evidence, which you can explore. Or it says “not enough evidence” and what it could not check. We measure the accuracy, and publish the method.
1 · What counts as a change
Every change, in one feed.
Most incidents start with a change. Epok keeps one change feed per service, so the question “what changed?” has an answer before anyone asks it.
- Deploys
Every rollout from your CI/CD system or a Kubernetes Deployment, with the service, version and time.
- Feature flags
Flag turned on, turned off or changed rollout percentage, from your flag provider.
- Config changes
ConfigMaps, environment values and infrastructure changes that alter how a service runs.
- Kubernetes events
Restarts, evictions, scaling and image changes, collected by the same Helm install.
2 · What Epok watches after a change
What your users feel, along the call map.
After a change, Epok compares the changed service and everything it calls, and everything that calls it, with their learned baselines. The eBPF call map shows those paths with no code changes. Epok looks at the signals that matter to users first.
User-facing symptoms
Error rate · latency · failed requests · failed page loads and front-end errors from RUM · new error signatures.
Silence
A service, a log stream or a metric that stops after the change. Silence is a symptom too.
Other deviations, such as resource trends, saturation and slow drifts, go on the timeline as context. They inform the answer but do not page anyone. Triggers and detectors.
3 · The answer
Three possible answers, each stated honestly.
No sign of harm
The signals Epok checked after the change, and that they stayed inside their normal range. You can open the same checks.
Not enough evidence
What Epok could not check and why: a service with no traces, two changes at once, a signal it does not receive. It also lists what to add so it can check next time.
Every finding opens in your own explorer: the log search, the trace, the metric query. You can edit the query and keep exploring. Your agents can get the same findings through MCP, with access on request. How the investigation works.
4 · The recovery step
Recover first, then find the root cause.
When a change hurt production, the recommendation is usually to undo it: roll back the deploy or turn off the flag. Each recommendation shows how easy it is to undo, the blast radius, and Epok's confidence.
When no change explains the incident, Epok recommends a restart, a scale-up or a failover, with the evidence for each. Root-cause analysis continues after service is back.
We recommend; you execute. Epok never changes production.
Suggested: Roll back the deploy on payment
A change immediately preceded the errors; reverting it is the fastest reversible mitigation.
5 · What to send
One install, plus your change sources.
- Telemetry
One Helm command collects logs, metrics, traces, Kubernetes events and the eBPF call map. RUM covers web, session replay and mobile.
- Change events
Kubernetes rollouts arrive with the install. Connect your CI/CD system and flag provider so every deploy and flag change joins the same feed.
- Coverage report
Epok tells you which services it can judge, which it cannot, and what data closes each gap.
6 · How the accuracy is measured
Measured on faults we did not tune on.
We test the change verdict and the recovery step on public fault benchmarks and on our own fault injection. The fault record stays apart from Epok. Each answer is scored correct, incorrect, abstained or missed, with rules fixed before the run and a holdout set that is never used for tuning. We publish the method.