Golden
Back to work
WatchNode logo
Product I built

WatchNode

Anomaly detection for logs and spreadsheets

A system I built for teams that need more than a threshold on logs or spreadsheets.

Problem

Rule-based alerts catch the failures you already named. They miss patterns in application logs, and in spreadsheets, that nobody has written a rule for. A detection on its own still leaves someone to decide what changed and what to do.

Solution

WatchNode scores logs and spreadsheet data from four perspectives: semantic, sequential, statistical, and temporal. Hugging Face inference runs in worker processes. A BullMQ queue on Redis keeps that scoring off the ingestion request. CSV uploads and bank-statement checks use the same idea. The hosted product is no longer online. The repository is the record of the system.

What I handled

I built WatchNode: the ingestion API, the workers, the detection flow, and the Next.js dashboard.

Architecture & Technical Decisions

An event-driven Node API and BullMQ workers. The workers call Hugging Face for anomaly scoring. MongoDB stores the application data. Redis holds the queues.

Detection

Semantic, sequential, statistical, temporal

Queue

Redis and BullMQ

Status

Not online. Code is public.

Architecture pattern
Event-driven API plus background workers
Hosting & deployment
Containerized Node services. The public site is no longer online.
Data layer
MongoDB for application data; Redis for queues
Integrations & services
Hugging Face inference, BullMQ, CSV and bank-statement analysis

Talk about a system like this

The write-up above is the record. If you want a system like it, send a note.