Why We Built Epok

We built Epok because we were tired of being the monitoring. Not the on-call rotation — the actual detection layer. We ran the services, we shipped the logs, and the thing that noticed when something broke was, reliably, a human being typing "is anyone else seeing 500s?" into Slack. Epok is the tool we wanted instead: one that watches your logs, metrics, traces, infrastructure, and RUM together, tells you what broke, and drafts the root cause with the evidence attached.

It didn't start as a company. It started as being annoyed.

The setup that kept failing us

A handful of services. Nothing exotic — an API server, a few workers, a Postgres, deployed on a small cloud box. Logs going to CloudWatch because that was the default and nobody wakes up wanting to choose a logging vendor. And no real idea when things broke until a customer or a teammate told us.

This wasn't negligence. We did the things you're supposed to do. We built Grafana dashboards. We wrote alert rules — thresholds, durations, for-clauses. We wired up Slack notifications. And every single time, the same decay set in within a few weeks. A threshold that made sense in March was firing constantly by April, so someone bumped it, so it stopped firing at all. The dashboards turned into wallpaper — glanced at once a day, load-bearing for nobody.

The failures that actually hurt us were never the ones the dashboards were built to catch. A worker that went quiet and stopped processing the queue — no error, no spike, just absence, and absence doesn't trip a threshold. A deploy that introduced a brand-new exception, buried under the normal log volume. A slow latency creep that never crossed the line we'd drawn, until it did, at the worst possible time. We'd instrumented for the failures we could imagine. The ones that took us down were the ones we couldn't.

The question that turned into the product

At some point one of us asked it out loud: why do we have to tell the tool what to look for? The tool has every log line. It has the metrics. It can see what normal looks like at 9am Monday versus 3am Sunday. Why is it sitting on all that and waiting for us to write a query?

That question is the whole product, in retrospect. The premise of a search bar — and of an alert rule — is that you can describe the problem well enough to ask for it in advance. But the incident is exactly the moment you *can't* describe it yet. That's what makes it an incident. A tool whose interface assumes you already know what's wrong is optimized for the one situation where you don't.

We wanted the inverse. Point telemetry at it, and get told. New errors caught the first time they appear. Volume anomalies flagged without anyone writing a query. A service going silent surfaced before it becomes an outage. And all of it working from the moment the first log arrives — not after a six-week tuning project. We ended up calling that idea detection-first observability, and it's the spine of everything Epok does.

What we decided not to build

A product is as much what you refuse to build as what you ship. We drew a few hard lines early, and we've held them.

No proprietary agent. Your existing shipper — Vector, FluentBit, Promtail, the OTEL Collector — works as-is, over standard protocols. We are not going to make you rip out your pipeline to try us.

No dashboard builder. We are not in the business of selling you a blank canvas and a weekend. The detection is the product; if we've done our job, you don't build panels to find out what's wrong, the tool tells you.

No cardinality tax and no surprise bill. Flat monthly pricing with included volume. We watched our own observability spend scale with our success and resented every dollar of it, so we priced the thing we wished existed instead.

And no feature-gating the intelligence. The detectors and the AI root cause run on every tier, including the trial. Locking the part that actually helps you behind the top plan is exactly the move we built Epok to get away from.

What Epok actually does now

Epok runs more than twenty detectors across every connected signal — new-error fingerprinting, volume anomalies (spikes, drops, flatlines, forecast breaches), silence and absence detection, pattern clustering, golden-signal monitoring, host liveness and disk/capacity forecasts, plus metric, trace, and RUM detectors.

But detectors that just page you are only half the job, and the louder half. The part we're proudest of is what happens after one fires. Epok reads the signals together and drafts the answer: which service is the probable cause, what changed, who's affected — and it cites every claim to the exact log line, span, or metric behind it. You read the verdict on one screen and click any sentence to check the receipt. We wrote up the mechanics in how multi-signal root cause works.

It also knows what it doesn't know. When the evidence is thin, Epok says so and lowers its own confidence instead of dressing up a guess as a finding. A tool that cries wolf is worse than no tool — it trains you to ignore it. The honest verdict is a feature, even when the honest verdict is "not sure."

Who we built it for

We built Epok for teams that look like we did. Small, moving fast, wearing too many hats, with nobody who gets to be a full-time SRE. If you're a team of five deploying three times a day, this is for you. If you're running a SaaS solo and you want to sleep knowing your phone buzzes when the service dies at 3am, it's for you. If you're paying more for observability than for the infrastructure it watches, it's very much for you.

The trial runs 14 days with every feature unlocked — full detection, full AI root cause, no credit card. Most teams find something in the first day that their existing setup was missing. Convert to a paid plan when Epok has solved a real incident in your stack, not before. (Current pricing starts at Team $199/mo for 1 TB/month — verify at getepok.dev/pricing.) That's the whole business model: prove it on your data first.

We built the monitoring we wanted, and stopped being the detection layer ourselves. We hope it does the same for you.

FAQ

What is Epok? Epok is a detection-first observability tool. It watches your logs, metrics, traces, infrastructure, and RUM together, automatically detects what broke, and drafts a root cause — which service, what changed, who's affected — with every claim cited to the exact log line, span, or metric. There are no dashboards to build and no alert rules to write.

Why is it called detection-first? Most observability tools are search-first: they store everything and hand you a search bar to go hunting during an incident. Epok inverts that — the tool finds the problem and proves it, so the first thing you see is the answer rather than a blank query box. The detection runs from the moment your first log arrives.

Do I have to replace my existing logging or metrics setup? No. Epok accepts data from your existing shippers (Vector, FluentBit, Promtail, the OpenTelemetry Collector) over standard protocols, and runs alongside your current stack. You point telemetry at it without ripping anything out.

How does Epok avoid false alarms? It learns each service's normal behavior per hour of day and day of week rather than using one flat threshold, groups related alerts into a single incident, and caps its own confidence when the evidence is thin — staying quiet rather than paging on a weak signal. The goal is to be a tool you can trust enough not to ignore.

How much does Epok cost? Epok offers a 14-day free trial with every feature unlocked and no credit card. Paid plans start at Team $199/month (1 TB/month), with Growth and Custom tiers above it; overage is billed per GB. There is no free-forever tier. Verify current pricing at getepok.dev/pricing.