Nullify: Incident management system by Aswin ShineNullify: Incident management system by Aswin Shine

Nullify: Incident management system

Aswin Shine

Aswin Shine

Incident management that turns an alert storm into one incident and needs a root cause to close it. FastAPI, PostgreSQL, Redis, React, deployed to EC2.


One incident per storm, and no close without a root cause.

Nullify is an incident management system. Every signal for a component folds into that component's one open incident; the component's type sets the priority, the SLA and who gets paged. An incident moves one step at a time, and it can't close until someone files the root cause analysis. I rebuilt its core in September 2026, tested it against a real Postgres, and deployed it to AWS EC2 from tag v2.0.0 with a pipeline that holds no cloud keys.

The product.

The first signal opens the incident and starts the SLA clock (a database is P0, 15 minutes). Someone takes it and moves it to Investigating, and every change lands in the audit history in the same transaction. Resolved isn't closed: Close stays disabled until the RCA is on file, and filing it records the MTTR that Analytics tracks by component.

On a real server.

Tagged v2.0.0 on 9 October 2026 and deployed to EC2 by the pipeline: nine test signals for KAFKA_BROKER_01 became one P1 incident with a one-hour SLA.

Orchid, light and dark.

One hue in two themes, Switzer for the interface, a mono stack for IDs and timers. Severity always carries its label, never color alone.

A storm in, one incident out.

A unique index in Postgres allows one open incident per component; the tests fire 100 concurrent signals and expect exactly one. Measured, not promised: the first README claimed 10,000 signals a second without measuring it. Measured, one transaction per signal managed about 525 a second; batching one transaction per component brought it to about 17,400 (bench_ingest.py, worst case, database write path only).

The parts.

Caddy (TLS, the only public port), nginx with a strict CSP, FastAPI on four workers, a batch writer, PostgreSQL 16, Redis 7 for fan-out across workers, and a JSONL lake that keeps every raw signal replayable. One EC2 instance built by Terraform; Slack and PagerDuty are called only after the commit.

Tag it, ship it, watch it.

A version tag runs ruff and pytest (80% coverage gate), eslint and vitest, seven security checks (gitleaks, pip-audit, npm audit, bandit, zizmor, terraform validate, promtool), Trivy on the images, a manual approval, then OIDC and SSM run the deploy with no SSH and no stored keys, and a health check rolls back on failure. Prometheus watches the app with eleven alert rules. 328 backend tests and 531 frontend tests.

What broke, and what's next.

A status race where both SREs won, a live feed split across four workers, a Postgres outage that lost 1,878 signals (1,875 recovered by replay), and scanners that reported all clear while scanning nothing. Next: automated backups, Alertmanager, a second instance, a durable ingest queue.
Like this project

Posted Oct 15, 2026

Incident management that turns an alert storm into one incident and needs a root cause to close it. FastAPI, PostgreSQL, Redis, React, deployed to EC2.