Know what broke, before your customers do
Your systems write about 400,000 log lines a day explaining exactly what is going wrong. Nobody reads them.
Harold does, and hands your team the ten that matter — with the root cause and the evidence already attached.
Every day your platform explains itself 394,630 times. Nobody is listening.
The line that explains the outage is already in the log file. At a few hundred thousand lines a day, dashboards show rates and averages, and the single stack trace, the scanner probing an admin path and the new error template that appears two hours before the failure never move an average.
Attention does not scale. Reading 400,000 lines a day is not a discipline problem, it is arithmetic. Sampling misses the events that matter, because they are rare by definition.
Thresholds fire after the symptom. Classic monitoring alerts when a metric crosses a line. The failing dependency and the credential-stuffing attempt are visible in the text well before that.
Understanding takes five tools. When an alert does fire, an engineer reconstructs the story across log viewer, metrics, provider console and chat history. Time to understanding is the real cost.
Sending everything to a model is not affordable. Analysing every batch with a language model costs more than the infrastructure it watches, and most of those calls confirm that nothing happened.
Three services joined by a queue, from raw log line to a closed incident
Collection, analysis and presentation are separate processes. The broker between them is what makes a model change or a worker restart a non-event.
Collect
DigitalOcean, Google Cloud Run and Cloud SQL, AWS Fargate and Heroku are read through their own APIs. A small shell agent covers any file, container or journald unit. RabbitMQ absorbs traffic spikes and survives worker restarts.
Decide & explain
Each batch runs the gate funnel. For genuinely new behaviour the model returns a structured verdict — severity, category, root cause, affected routes, the evidence lines and a recommended action — never free text.
Correlate & respond
Related alerts share a fingerprint and collapse into one incident with a timeline, an owner and a status. Hostile addresses and routes can be blocked at the Cloudflare edge and inside the application, from the same screen.
Eight gates run before the model. The first one that can decide, decides.
Gates 1 to 8 are local: no external service, no tokens, single-digit milliseconds. Gate 9 is the only one that spends money — and on a live deployment about one analysis in three never reached it.
Operator-defined patterns and paths dropped before anything runs. Known benign noise costs nothing.
Scanner paths, SQL injection and traversal payloads produce an instant verdict with no model call.
Authentication failures counted per account over a sliding window, so brute force behind a CDN is still caught.
Client addresses matched against an imported reputation feed. A known malicious address resolves the batch at high severity.
Configured log signatures reuse a previous verdict for a known recurring issue, invalidated when the prompt changes.
Log templates are mined continuously. A batch built only from templates already seen contains nothing structurally new.
A local model learns each application's error rate, status mix, route and address diversity, then flags deviation.
Identical log structures reuse a recent verdict; near-identical ones match by similarity after normalisation.
Reached only when the batch is structurally new or statistically unusual. Sensitive values are redacted first; the model returns a structured verdict, never free text.
An explainable score combines detector signals with deviation from the application's own baseline. The alert joins an incident and reaches the right channel.
Each gate is cheaper than the one after it. A scanner hitting /.env is answered at gate 2 in zero seconds and never reaches a model that would have charged for the same conclusion. Doubling traffic that repeats itself does not double the bill.
In a census of 60,000 consecutive analyses, 33% were resolved by the local gates — familiar behaviour, a reused verdict, a known attack pattern or a known hostile address. That single ratio determines the running cost, and the Batches screen reports it per application.
Six detectors, each good at something the others miss
None of them depends on a language model, which is why they can run on every batch without a cost ceiling.
Attack signatures
Requests for credential files, version-control directories, admin panels and database dumps, plus injection and traversal payloads. Instant and reproducible.
Sequence detection
Authentication failures aggregated per account over a sliding window. Counting accounts rather than addresses keeps it effective behind a CDN.
Threat intelligence
A reputation feed of known malicious addresses, matched on every batch. Hits are raised at high severity with the offending lines attached.
Template mining
The set of templates an application emits is learned continuously. A line whose shape has never been seen is the earliest available signal of a new failure mode.
Statistical anomaly detection
A per-application baseline over error rate, warning rate, status mix, route and address diversity and latency. Deviations name the feature that moved and by how much.
Explainable risk score
Detector signals and baseline deviation combine into a score with a confidence value and a list of contributing signals. It recommends observing or acting, and never blocks on its own.
916 hostile events in six days, on systems that were considered quiet
Continuous scanning is the normal background of anything exposed to the internet. The difference is whether you can see it and act on it.
The rate of hostile events, continuously
Across every exposed application: 779 scanning attempts probing for files and panels that should never be requested, and 137 requests from addresses on a maintained threat list — recognised instantly, at no analysis cost.
Blocked before it costs you
Hostile traffic is dropped before it reaches your servers, so a scanning campaign does not turn into an infrastructure bill or an incident.
Blocking, not just reporting
An address or a route can be blocked from the same screen that found it. The block is pushed to your edge provider and enforced inside the application.
A record for the auditor
What was detected, when, what was decided and by whom — available months later, in one place, without reconstructing it from four systems.
One platform, from raw log line to a closed incident
Every capability below is in the shipped product and visible in the running deployment.
Reads the platforms you already run
Cloud sources are discovered through their own APIs. Everything else uses a small, scoped agent.
| Active | Name | Application | Status | Actions |
|---|---|---|---|---|
| api | app-one | Active | EditPull logsDelete | |
| web | app-one | Active | EditPull logsDelete | |
| worker | app-one | Active | EditPull logsDelete | |
| gateway | app-two | Active | EditPull logsDelete | |
| api | app-two | Inactive | EditPull logsDelete | |
| web | app-two | Inactive | EditPull logsDelete | |
| jobs | app-three | Active | EditPull logsDelete |
391,703 lines in a day, reduced to ten items worth opening
Cost tracks novelty, measured on a live deployment
A census of 60,000 consecutive analyses over six days: one in three resolved by the local gates. The reference deployment handles roughly 400,000 lines a day on shared infrastructure with two worker consumers.
Recoverable by design
Every batch carries a status of pending, processing, completed or failed. Batches stuck in processing are republished automatically, and any batch can be replayed from the interface.
Scales horizontally
Add workers when volume grows. Collection and the interface are untouched, and the queue distributes work automatically. Redis coordinates rate limiting across workers.
A monitoring platform holds the most sensitive text in the estate
Harold is built on the assumption that it is itself a target, and that log content must be treated as personal data by default.
Redaction before analysis
API keys, tokens, authorization headers, JWTs, passwords, e-mail and network addresses and identifiers are replaced with stable placeholders before any text leaves for a model.
Data can stay inside
With a locally hosted model the whole pipeline runs inside your perimeter and no log content reaches a third party. The interface, or only the ingest endpoints, can be limited to specific addresses or a VPN.
Least privilege and audit
Invite-only, passwordless sign-in with three roles separating reading from operating from administering. Provider tokens live in an encrypted vault, and sensitive actions are written to an audit log.
The same job, done three ways
Threshold monitoring
Alerts when a metric crosses a line, after the symptom shows. It cannot read the stack trace, the scanner or the new error template in the text, and it says nothing about root cause. The engineer still reconstructs the story by hand.
Send every batch to an LLM
Explains well, then bills more than the infrastructure it watches. Most calls confirm nothing happened, latency rides on a third party, and by default your raw log content leaves your perimeter.
Reach for the model last
Eight local gates answer most batches for free; the model is called only for genuinely new behaviour. Every alert carries root cause and evidence, blocking is one click, and the whole thing can run inside your perimeter with auditable decisions.
| Capability | Threshold monitoring | LLM on every batch | TVL Harold |
|---|---|---|---|
| Reads every line, not a sample | No | Yes | Yes |
| Root cause and evidence in the alert | No | Yes | Yes |
| Flat cost as traffic repeats | Yes | No | Yes |
| Catches scanning & known-hostile traffic | Partial | Partial | Yes |
| Alerts collapse into owned incidents | Partial | No | Yes |
| Block at edge and in-application | No | No | Yes |
| Runs fully on-premise / local model | Partial | Rarely | Yes |
| Every decision replayable for audit | No | Partial | Yes |
Built by a team the European Commission trusts
EBSI, for the European Commission
Our CTO designed and audited the smart contracts behind the EU's European Blockchain Services Infrastructure.
Enterprise scale
Our CEO scaled eMAG Marketplace to $1B ARR, and sits in the European Commission's AI Group of Practice.
Trusted & recognised
Trusted by DataDiggers. NATO DIANA mentor and judge. A senior, international team in Luxembourg, Romania and the US.
Two weeks, one production application, three numbers
The pilot is designed so the decision at the end is made on your traffic, not on this page.
Week 1 · Connect and calibrate
We connect the sources for one production application, watch what it raises, and switch off the patterns your team recognises as normal. Nothing changes in your systems.
Week 2 · Run it for real
Findings go to the team that owns the application, in the channel they already use. They work them as they would any other item.
Day 15 · Decide on evidence
We review three numbers together — was it worth opening, did we learn something new, what does it cost to run — and you decide whether to extend, adjust or stop.
The questions your risk officer will ask
Point Harold at one application
A two week pilot on your own traffic. We connect it, tune it in the first days, and review three numbers with you at the end. If they don't convince you, we stop there.
Book a 30-minute scoping call. Tell us one production application and we'll take it from there.
Prefer email? Write to