DEV Community

Kishan Kumar
Kishan Kumar

Posted on

I built a tool that answers "what changed?" when production breaks

#devops #sre #webdev #showdev

It's 2 AM. PagerDuty goes off. You open your monitoring tool and it tells you, with great confidence, that checkout latency is up 400%. Thanks. Extremely useful.

Now the actual work starts: what changed? You open the deploy history in one tab, the feature-flag dashboard in another, the migration log in a third, Slack in a fourth, and you spend twenty minutes doing timestamp archaeology while the pager keeps screaming.

Every on-call knows this drill. The cause is usually a recent change - a deploy, a flag flip, a migration. Finding it is the slow part.

I got tired of doing it by hand, so I built LastGood.

What it does

LastGood ingests your alerts (generic webhook or Datadog), GitHub deploys, DB migrations, and feature-flag flips into one timeline per service. When an alert fires, it scores recent changes by time proximity and type, and highlights the most likely suspects:

"This deploy 23 minutes ago correlates with this error spike."

The result lands as one quiet card in your Slack. No dashboard you're supposed to stare at, no agent to install, no telemetry crawl.

There's a sandbox with sample data if you want to poke at it without signing up: https://console.lastgood.space/sandbox

How the scoring works (honestly)

It's heuristics, not magic. Right now the score is roughly:

  • Timing - how close the change was to the alert (exponential decay, not a step function, because "4 minutes ago" shouldn't automatically beat "40 minutes ago")
  • Change type - a migration is more suspicious than a README update. The classifier actually looks at what files changed: docs-only changes get ruled out explicitly, config/schema changes get boosted
  • Service criticality and topology - a change to a critical service, or to a direct dependency of the alerting service, ranks higher
  • Blast radius and change frequency - services that change constantly get less benefit of the doubt

Every score comes with its reasons attached. "Ranked #1 because it's a direct dependency of checkout-service, 6 minutes before the alert" - because a magic number helps nobody at 2 AM.

I'm genuinely skeptical of my own weights here. If you've run incident response, I'd love to hear what signals I'm missing.

Stack

React + Node/Fastify + Postgres (TimescaleDB) + Redis, Docker on a single EC2. The boring kind of stack that lets a solo dev ship.

What I'm building next

  • Topology that earns its keep - a graph of your services with suggested edges ("checkout-api alerts followed payment-api deploys 3 times - connect them?"), so correlation improves the longer you use it
  • Config-as-code - declare service criticality and dependencies in a lastgood.yml in your repo, version-controlled next to the code it describes
  • More ingestion - feature-flag providers beyond the current webhook

The honest part

I launched on Product Hunt last month and it brought exactly zero users. So this time I'm doing it differently: talking to people, posting in places I actually read, and asking for brutal feedback instead of upvotes.

Free tier covers 2 services, no card required. If you're the person who gets paged, I'd love to know what you think - especially if you think the whole approach is wrong.

Top comments (0)