Make production boring
Your system scales. Human attention does not.
Your architecture, code, pipelines and infrastructure change hundreds of times a week, and every change moves what normal looks like. None of that is going to slow down.
The industry answered with more dashboards and more people on call. Both of those scale linearly. Systems compound. That gap is not a staffing problem you can hire through - it is arithmetic, and it widens every quarter.
So something has to hold the entire system at once - continuously, at whatever size it reaches - and reason across all of it in one place. That is what the Discovery Engine is, and it is the whole of what Dalton is built on.
- 01Architectureevery service, dependency and version
- 02Codeevery commit, pull request and config change
- 03Pipelinesevery build, deploy and rollback
- 04Infrastructureevery limit, quota and node
- 05Productionevery metric, event and log
- ∞And it never holds stillre-indexed on every change, at any size
Three indexes. One living map of your system.
Connect what you already run. The Discovery Engine learns structure, behaviour, and meaning together—then never stops rebuilding them into the operational map Dalton uses to investigate.
One figure, four passes over the same seven services. First the graph index, the topology: checkout-svc, mobile-bff and admin call payments-api, which depends on auth-svc, redis-cache and db-primary. Then the tabular index: every service as a row over time, where the db-primary pool starts climbing at 03:41, two minutes after v2.14.8 deploys. Then the vector index: the same services arranged by meaning, where db-primary sits beside INC-2291, a pool exhaustion seen before. Finally everything converges into one living map, fed read-only by the tools you already run, and the conclusion resolves: v2.14.8 uncapped the pool, and checkout is downstream of it.
- 01 Graphwhat talks to whatcheckout-svc → payments-api → db-primary
- 02 Tabularevery metric and event, over timeclimbing since 03:41, two minutes after the deploy
- 03 Vectorwhat logs, code, and docs meanalready seen — INC-2291, last March
- 04 One living mapall three, on one surfacethe answer was already there
Every deploy, config drift, version mismatch, and slow RAM climb lands on the map. That is what lets Dalton connect signals no threshold would ever put together - and see the shape of a failure before it finishes forming.
The map persists. Dalton does not relearn your system every session, and it does not get slower as your system gets bigger.
Everything is investigated. Almost nothing reaches you.
Every alert, every event, and everything Dalton's own detection turns up gets investigated - continuously, in parallel, whether or not anyone asked for it. What reaches you is what survived: a cause, and the chain that proves it. That is what a boring week is made of.
- 01t + 00:12metricsdb-primary connection pool at 98% and climbing. It has been climbing since 03:41.
- 02t + 00:31eventscheckout-svc v2.14.8 reached 40% of the fleet at 03:39. Two minutes before the climb.
- 03t + 00:44codeCommit a3f2 removed the cap in getPool(n). Pool size is now unbounded.
- 04t + 01:02logs1,204 acquire timeouts. Every one on a v2.14.8 pod. None on v2.14.7.
- 05t + 01:18configmax_connections is still 256. The ceiling did not move. The demand did.
When one does reach you it arrives whole: five or more correlated pieces of evidence across logs, code, metrics, events, and config. A timeline. A blast radius. A mitigation, up to a ready pull request - proposed for review, never applied on your behalf.
Sometimes the conclusion looks wrong. Open the evidence and you usually learn something about your system you did not know. Still disagree? Steer it, add what it is missing, or reject it outright. Dalton investigates again, and remembers why.
The most dangerous alert is the one you never wrote.
Your worst outages do not cross a line you drew. They happen where you never drew one. Dalton watches how your system actually behaves, not just the rules you wrote about it - so the failure you never thought to alert on still reaches you. As an investigation, not a postmortem.
It watches with you. And it talks back.
Tell it about tomorrow's launch and it watches with you. When something does move, it arrives as one message with the cause already attached - not three pages to three people.
The checkout latency, the mobile-bff timeouts, and the db-primary pool alarm are the same thing.
getPool(). Pool size is unbounded.- checkout-svcp99 240 ms, up 18% vs 7dsymptom
- mobile-bff12 upstream timeoutssymptom
- db-primarypool 61 / 256, climbing since 03:41symptom
Suggested: restore the cap. PR #482 is open for your review.
what happens if we just roll back instead
Rolling back to v2.14.7 clears it, and costs you the checkout fix that shipped in the same release. Restoring the cap keeps both. Either way I will watch the pool for an hour after and tell you if it climbs again.
Every signal worth your attention lands in one feed. Slack-native, routed to whoever is actually on, grouped by cause instead of repeated once per symptom.
Ask Dalton to check something the way you would ask a teammate. Tell it about tomorrow's launch so it watches with you. Trigger an investigation on any question, business or technical.
First response in under 2.5 minutes, always.
- Investigates
- Every alert and anomaly, chased to a cause before it reaches you.
- Answers
- Ask it anything about production, the way you would ask a teammate.
- Watches
- Tell it about tomorrow's launch and it watches with you, before anything breaks.
Your data stays put. Only the signals move.
A boundary diagram. On your side of the line: raw telemetry, log payloads and your data stores, all of which stay exactly where they are - the firehose stops dead at the boundary. Crossing the boundary to Dalton, batched and never streamed: signals and their shape, Kubernetes resource data, and deploy, config and version events. On Dalton's side, what you control: declared queries only, you whitelist and Dalton runs exactly that, and read-only on every source. Nothing sits on your hot path and nothing is applied for you.
The collector batches everything and pulls Kubernetes resource data only. Your data stays where it is - we take the signals, not the firehose. Nothing sits on your hot path, so there is nothing to slow down and nothing to fall over when traffic spikes. That is what lets reliability scale without scaling the SRE team.
For expensive stores like BigQuery, declared-queries-only mode means Dalton runs exactly the queries you whitelist and nothing else. So the bill is one you can predict before you sign, and the blast radius stays the same size as you grow.
- Read-only on every integration by default
- Writes need your explicit approval, per action, with a revoke path
- Declared-queries-only mode for data stores
- Memory with an audit trail: see who taught Dalton what, when - edit it, roll it back
- No agents to install - nothing of ours runs on your hosts
- Your data never trains anyone else's model
Dalton keeps the map, not your data. We index structure, signals, and what Dalton has learned - raw telemetry stays in your systems, and everything that leaves is documented per integration.
We tripled reliability without tripling our SRE team — the traditional model just does not scale.