ErrorBook Dashboard

Inspiration

A developer spends 40 minutes debugging a build that fails because DATABASE_URL is missing. They find the problem, fix the configuration, and get back to work.

The next week, their teammate hits the exact same error. They spend another 40 minutes debugging it from scratch. The fix already exists somewhere in the team's collective experience, but as far as the teammate (and their AI coding agent) knows, the problem is brand new.

The problem isn't that we can't solve errors. It's that we keep encountering the same ones without a reliable way to preserve and share what we've learned.

Coding agents make debugging easier, but each new session can lack the context of what the team has already learned. We wanted to build a shared memory for development: a place where fixes survive beyond the session that discovered them.

That's why we built ErrorBook.

What it does

ErrorBook catches failures in your terminal and shares fixes through git. You run your normal command through errorbook run. If it fails, ErrorBook:

Fingerprints the error, so the same problem on two laptops gets the same ID.
Checks the team notebook first. A known error shows the fix, who found it, and how many teammates confirmed it, in milliseconds with no AI call.
Explains unknown errors in plain English using Gemini, then asks whether to save your fix. The demo errors use a committed cache, so they work offline and are labelled as prepared content.
Shares fixes with errorbook sync, which moves them through git.
Works with coding agents: errorbook mcp is a read-only MCP server. We tested it with Claude Code, which called it and checked whether the team's fix fit the project.
Team tooling: doctor checks setup, scan re-checks the notebook for credentials, digest and dashboard summarise what keeps breaking, suggest points at source fixes, and lookup answers from the notebook without running anything.
Hit rate: every run records a lookup event (hit, loose or miss, no error text). The dashboard shows a measured rate when lookups exist, and a labelled estimate otherwise.
Auto-confirm when a stored fix works, so fewer prompts are needed.

It also ranks competing fixes by confirmations, keeps failed fixes visible so nobody retries a dead end, and warns when you run the same failing command three times.

How we built it

Node.js, with no framework.

Capture wraps the child process, streams output live, and keeps the tail of stderr.
Fingerprinting normalises paths, usernames, timestamps, ports and git identity, so errors match across machines.
The notebook is append-only .jsonl, one file per person, so git never conflicts. Counts are derived when read, never stored.
A scrubber masks credentials before anything is written to git.
The explainer uses Gemini, with a committed seed cache so the demo works offline.
The MCP server is a hand-written, read-only JSON-RPC server over stdio, with no extra dependencies.
The dashboard is a single self-contained HTML file.

Challenges we ran into

Making fingerprints match across machines. Git's identity error embeds the user's email, and npm logs contain usernames and timestamps. Matching across laptops took several rounds of normalisation fixes.
Concurrent teammates. Mutable counts would conflict in git, so we store events and count on read.
Keeping secrets out of git history, since error text routinely contains connection strings.
Gemini's free-tier rate limits, which pushed us to a committed seed cache for the demo errors.
Windows quirks, including shell path differences and locked folders, which broke our own demo scripts several times.

Accomplishments that we're proud of

A fix saved on one laptop appeared on a second laptop in 16 ms, with the same error ID despite different git emails.
A coding agent (Claude Code) called our MCP server, got the team's fix, and checked whether it fit the project before using it.
Twelve test suites passing, with 271 named tests plus 78 assertion checks (capture's 20 and fingerprint's 58). They cover fingerprinting, the notebook, sync, the CLI, the dashboard, the MCP server and every new command.
Competing fixes ranked by confirmations, with failed fixes kept visible.

What we learned

Memory beats intelligence for repeat problems. The AI is the slow, rare path. Most of the value comes from recording what people already did, and the hard part is making two people's versions of the same error look identical.