The moving field at the top of this page is an illustration, not live data.
3ER · by 3EyedRaven · See · Understand · Explain
3ER reads the events of everything you run and writes down what is actually wrong. One problem gets one plain sentence: what happened, where, since when. Beneath it are the exact lines that prove it. And all of it stays inside your own walls.
How it works · one night at 02:14
At 02:14 a port on core-switch-03 starts failing. Six systems start talking, and none of them says what is wrong. This is what 3ER does with that night, in six steps. An illustration with invented systems.
The interactive walkthrough of the 3ER console needs JavaScript. In words: events are counted as they arrive; a real problem becomes one Situation, named in a plain sentence; 3ER shows what changed before it began, what began with it and what is around it; every line that proves it is kept; Raven answers questions with a citation for every statement; and the story becomes a finished, cited report.
ISee
The stream
Every switch, server, database and application writes down what it does, all day and all night, each in its own dialect. Somewhere in that stream is the line that matters, the moment a problem begins. It arrives beside a flood of lines that do not, often at an hour when nobody is reading.
3ER starts from a different question: what if the stream could simply be read, and the answer written down?
The Situation
A Situation is one real problem written as a plain sentence: what happened, where, and since when, with the exact lines that prove it beneath. It is not a colour, a score or a ticket. It is a sentence you could read aloud to someone who has never seen the system.
Repeats fold into the problem they repeat. Two different problems stay two Situations, side by side. Inside 3EyedRaven we hold the work to a blunt rule:
A false alert is a crime.
Kind of problem
3ER recognises problems against a fixed catalogue of kinds, about four dozen of them, each precisely defined. A disk filling on a database in one building and a disk filling on a file server in another are the same kind of problem, named the same way, every time.
Because the kind is known, so is its history: how often it has happened here, how it behaved and how it closed before. A new problem arrives with its past attached.
IIUnderstand
Rules, not guesses
Situations are not written by a language model. They are formed by fixed, deterministic rules, so the same records always produce the same Situation: the same sentence, the same evidence, word for word. Replay last Tuesday and you get last Tuesday's answer.
Each Situation shows its working as facts: what was matched, and over which window. No confidence scores. No adjectives.
Identical, word for word.
Nothing happens alone
A sentence tells you what is wrong. The questions that follow are always the same, and 3ER gathers the answers onto the Situation before you ask:
What's around this problem
No system has a problem alone. For every Situation, 3ER draws its neighbourhood: the systems connected to the one in trouble, and which of them have joined the problem. Then it replays the order in which they joined, so instead of rebuilding the night from memory, you watch it happen again.
The order is shown exactly as it was recorded. The reading of it is yours.
Silence
Some problems never raise their voice. A system that stops sending anything can look exactly like a system that is fine. 3ER notices the quiet: which systems have gone silent, since when, and the last records each one sent before it stopped.
Memory
When your team agrees not to raise something, like the nightly restart of storage-svc between 01:00 and 01:30, the agreement holds, recorded where everyone can see it. And when a problem keeps happening, 3ER says so plainly, so a recurring problem is never treated as news.
Honesty
02:14:20Port 1/0/44 on core-switch-03 went down
02:16:05Port 1/0/44 on core-switch-03 keeps failing: 6 changes in 2 minutes
A newer, better claim replaces the older one, and the trail is kept. You can always see what 3ER said first, what it says now, and which evidence made the difference.
IIIExplain
Raven
Raven is 3ER's analyst. Ask it about a Situation in your own words, and it answers from that Situation's own evidence.
The port went down and up 14 times between 02:14 and 02:20[1][2]. Five minutes before the first failure, at 02:09, its configuration was changed[3]. Each time it went down, edge-router-7 lost its neighbour[4] and payments-api timed out upstream[5].
Check next, read-only: the port's error counters · compare the 02:09 change with the one before it
The storyline
The board of open problems leads to a Situation. The Situation leads to its evidence, down to the single line. The evidence leads to Raven, and Raven's answers lead to a report: the story, finished, ready to hand to whoever needs it next, carrying the evidence so the next reader can check it the same way you did.
Bounded by design
Most systems grow slower as they remember more, because every question has to wade through everything that came before it. 3ER was designed the other way round: it keeps its answers current as each new record arrives, instead of re-reading history to answer you.
History accumulates. It never gets in the way.
Principle zero
Everything on this page happens inside your own walls, on your own hardware.
3ER needs no internet connection, no cloud account and no outside AI service. When Raven writes with a language model, that model runs inside the appliance with everything else.
Your records stay where they were written. Your questions stay with the people who asked them. The answers stay with you.
Not the data. Not the questions. Not the answers.
We'll walk you through 3ER privately, on your own ground.
Arrange a private walkthroughcontact@the3er.com