Skip to main content
TL
Illustration: scattered errors converge into a central engine and come out sorted into records.

Error knowledge base

Giving a team a tool it actually uses, to see its errors and fix them fast.

Role

Design and development

Period

Technical stack
  • NestJS
  • TypeScript
  • React
  • TypeORM
  • PostgreSQL
  • Azure Functions
  • Azure OpenAI
  • Entra ID
projects wired in
7
documented errors
~200
to v1 in production
5 jours
time to resolution
< 1 sem.
01

The context

  • When a developer hits an error a colleague has already solved, nothing keeps the cause or the fix: they ask someone or rediscover the problem from scratch.
  • That knowledge stays in people's heads and scatters from one project to the next; a departure or a change of team takes it away.
  • The team tracks its errors poorly: nothing surfaces them in one place, and on several projects it does not know which ones run in production, where they can drift for months.
  • Someone else built a first version for a different need, which drifted toward the knowledge-base idea; the app does neither, and never reaches the intended adoption.
02

My mission

  • Re-scoping around the team's real need, after a first version that went unused.
  • Designing and building the application end to end.
  • Defining the ingestion contract and how each application sends its errors, whatever its stack.
  • Designing how errors group into records, and the automatic triage rules.
  • Setting up the delivery pipeline on Azure DevOps, with Sonar analysis, Fortify SAST and dependency scanning.
  • Informing the teams weekly and gathering feedback to remove friction points in use.
03

Decisions and trade-offs

  1. 01

    Re-scoping and rebuilding instead of taking over the existing app

    Problem

    A first version exists but meets neither the original need nor the team's, and does not reach the intended adoption.

    Solution

    Re-scoping onto the real need, then rebuilding and shipping a v1 in one week.

    Why this choice

    Scope is the real problem, more than the code; taking over the existing app would have carried the wrong perimeter forward. Since then, on projects blind for months, the team fixes errors within days and their flow drops from several a day to one a week at equal usage.

  2. 02

    Building a knowledge base rather than an off-the-shelf error tracker

    Problem

    The team has no error tracking, and products like Sentry would cover reporting and alerting.

    Solution

    In-house ingestion and grouping of errors into records, where the team fills in the cause and the fix by hand. All of it on the Azure hosting and Entra ID authentication in place.

    Why this choice

    Sentry reports events, where the team wants knowledge it maintains: cause, fix, a per-project reference answer. In exchange, the grouping and the rules are ours to design and maintain.

  3. 03

    Recognising the same error across its different forms

    Problem

    One cause can show up under several HTTP codes, and grouping too finely creates one record per variant for a single problem.

    Solution

    The fingerprint groups by project, context (route or operation) and exception type, deliberately leaving out the status code. Per-project rules normalise the context to absorb scanner noise.

    Why this choice

    The status code varies without changing the underlying problem; including it would split one cause across several records. The right grouping level is then tuned per project.

  4. 04

    Decoupling log reception from writing to the database

    Problem

    Applications emit logs at a sustained rate, and one database write per log would be costly at that pace.

    Solution

    The API acknowledges receipt at once and stacks logs in memory, then writes them to the database in batches at short intervals.

    Why this choice

    Batching holds the throughput where one write per log would make the database the bottleneck. In exchange, a crash loses the last batch still in memory, which stays acceptable for telemetry.

04

What this project gave me

  • Taking over an internal product and re-scoping it onto the real need before writing a line.
  • Driving adoption of a cross-team tool through weekly updates and regular feedback loops.
  • Co-building the ingestion contract with the team, leaning on the people who know the stacks outside one's own expertise.
  • Designing an integration agent that drops the client into a repository and opens the PR by itself, adapting to the stack.
  • Using AI tooling to speed up design and shift attention onto code review and security.

Gallery

See other projects