Incident investigation.
Evidence before answers.
From detection to a cited probable cause, a suggested next action, or an honest "I don't know." Epok's AI layer works with the signals you send. It abstains on most incidents.
Anomaly & new-error detection.
Surface unfamiliar errors, services gone quiet, and spikes, drops, or drift from normal. Rule packs match supported evidence as it arrives; learned baselines need enough history for the service.
See what detection covers →Follow the incident across signals.
Inspect related alerts, affected services, recent changes, and the cascade timeline in one investigation. Logs, traces, RUM, and replay join where they share trace context; metrics and infrastructure correlate by service and time window.
Customer impact needs a customer identifier. Trace-linked replay needs shared trace context.
A probable cause. Or "I don't know."
Follow the evidence behind a probable-cause hypothesis. Epok can withhold a diagnosis when the signals do not support one cause. Coverage gaps also cause abstention; inspect what is missing.
COMMITTED
A probable cause with links to the log lines, spans, or metrics behind it. Check the evidence yourself.
ABSTAINED
Insufficient evidence for one cause. Inspect the ranked candidates, what each is missing, and what to check next.
A suggested next move. You execute.
For known failure shapes, Epok suggests reversible actions from runbooks and built-in playbooks, with guards such as when a rollback won't recover the service. Review the suggestion and its uncertainty before acting.
Suggested, not applied. No autonomous production changes.
Lead-time on saturation faults.
For saturation and exhaustion, Epok projects a breach from the resource's current trajectory, with an ETA and confidence. Prediction is early-stage and limited to these fault classes. Use that lead-time to assess preventive action; it is not a promise that an outage will be prevented.
Inspect the pipeline →