DEV Community

impactcheck
impactcheck

Posted on Fully Autonomous

We Got Paged at 2am Because Someone Removed a Method

It was a Tuesday.

A developer on our team cleaned up some old code and removed a method that looked unused.

The tests passed.
The PR was approved.
It was merged.

Six hours later — at 2am — POST /caption/assign started returning 500 errors in production.

The method wasn't unused.

DriversController.assignDriver was calling it. The controller handled a live endpoint. The endpoint was in production. Our tests simply didn't cover that path.

That's the kind of incident that ruins your week — and makes you question everything.

Breaking changes are rarely obvious

If they were obvious, developers wouldn't make them.

The dangerous ones are often structural:

A method gets removed.
A signature changes.
An endpoint disappears.
A caller still depends on the old contract.

The code looks fine locally.
The tests pass.
The linter is happy.

Nothing tells you that three other parts of the system just broke.

You usually find out in production.

And sometimes, it's at 2am.

So we built ImpactGuard

ImpactGuard is a CLI that detects structural change impact before your PR gets merged.

Two commands:

npx impactcheck-cli init
npx impactcheck-cli check

Run init once. Run check after your changes.

When we simulated the incident above, ImpactGuard reported:

⚡ ImpactGuard — checking impact

⛔ 1 BREAKING — push blocked

⛔ Method Removed [95%]
DriversService.assignNearestDriver
callers : DriversController.assignDriver
api : POST /caption/assign
────────────────────────────────────────────

Not checked: logic changes · feature flags · DB migrations
dynamic calls · polymorphism · cross-service (Phase 3)

One removed method.
One real caller.
One production endpoint.

Caught in three seconds — before the PR was raised.

That 2am incident would never have happened.

How it works

ImpactGuard scans your source code locally and builds a call graph: a map of which methods depend on which other methods, and which API endpoints ultimately reach those handlers.

When you run check, it compares the current code against the baseline and traces the impact of structural changes.

Your code change

Methods changed or removed

Callers that depend on them

API endpoints those callers belong to

Impact report with evidence

Nothing is sent anywhere.

No server.
No account.
No environment variables.

It reads your source files directly.

The rule that matters: warn only when there is a consumer

This was one of our most important design decisions.

Remove a method that nothing calls?

Silence.

Change a signature that has no consumers?

Silence.

Only warn when something actually depends on what changed.

And every warning includes evidence: the affected callers, API endpoints, reason for the warning, and a confidence score.

We believe developers stop ignoring warnings when they can trust them.

What it doesn't catch

We don't want to pretend static analysis is magic.

ImpactGuard is a static call-graph analyser, not a runtime oracle.

It currently does not catch:

Logic changes inside methods
Feature-flag behaviour
Database migrations
Dynamic calls such as servicemethod
Cross-service dependencies (coming in Phase 3)

We show these limitations in every report.

The goal isn't to claim we catch everything.

The goal is to catch the structural changes that can cause immediate runtime failures — before they become production incidents.

Try it on your project

In your project

npx impactcheck-cli init

After making changes

npx impactcheck-cli check

It works with Node.js, NestJS, Express, Fastify, Spring Boot, FastAPI, and Flask.

No account.
No signup.
No server.

Just two commands.

We want to test it against real code

If you try ImpactGuard, we'd love to know:

Did it catch something you wouldn't have noticed before raising your PR?
Did it miss something you expected it to catch?
Did it flag anything incorrectly or unhelpfully?

Open an issue at github.com/impactcheckcli/impactguard-cli or reply here.

We built ImpactGuard because we got tired of discovering breaking changes in production.

The 2am page isn't a rite of passage.

It's a process failure.

ImpactGuard is our attempt to fix that process — one PR at a time.

Top comments (0)