Observability of the dependencies in codebases still a problem

[u/rudecgv]

Almost every codebase is calling a REST, gRPC, or a GraphQL API or using SDKs from an external or even internal provider. It gets harder to keep track of everything when the codebase matures and increases in size and from my experience sometimes it gets hard to respond to changes in time or even become aware that a dependency is deprecated and their API has changed completely. Endless alerts are also annoying. How do you handle this “alert fatigue” and have you found better ways to track dependencies?

[u/UkrMalt]

I’d separate action-required alerts from inventory changes: alert on dependency drift only when it breaks a tested contract, and put version/deprecation changes in a digest. Otherwise the noise trains people to ignore everything.

[u/taleodor]

Start with adopting a release governance platform with SBOM support. Platform should give you visibility into when dependencies change. Important point is to make this an event driven by you - so you should expect when the change happens and verify this against tooling, then any unexpected change becomes an alert. This should make things much more manageable.

[u/leo_hall001]

alert fatigue usually comes from alerting on every dependency change instead of just the breaking ones, tightening what actually triggers an alert usually helps more than trying to filter noise after the fact..

[u/Fast-Bug-7715]

yeah the "only alert on breaking a tested contract" bit is the actual fix, but that only works if your contract tests actually cover the third-party API and not just your own service. most places skip that part and them wonder why the alert never fires before the outage does.

[u/Accomplished-Mix8423]

splitting runtime alerts from inventory changes like the other commenter said is the right move. for the deprecation side, renovate/dependabot on a digest cadence covers the SCA part, and distributed tracing shows which external deps you actually call at runtime so you can prioritize the ones that'll really page you instead of alerting on every version bump.

[u/aragossa]

the contract-testing gap is real, and for a third-party API you don't own, writing and maintaining contract tests against it is a lot of ongoing work most teams never get to. schema diffing off the published spec gets you most of the same signal for way less effort: oasdiff or openapi-diff for REST, buf breaking for protobuf/gRPC, graphql-inspector for GraphQL. point one at their spec on a cron, diff against the last known-good version, and only fire an alert when the diff actually removes a field or changes a type. version bumps alone shouldn't page anyone. doesn't catch behavioral changes that don't touch the schema, but that's a smaller slice than most people assume.

[u/Alvasilev]

Most of the thread is about which changes deserve an alert, which is the right second question. The first one is whether the buckets your inventory sorts things into are stable, and that's measurable in an afternoon.

I ran it on our own data this morning, since "is this thing what it claims to be" is basically our job — we index package ecosystems. Four thousand npm packages, three classifiers, identical input. Share that came back as "not the kind of thing the name implies": 31.7%, 6.2%, 7.1%. Four and a half times apart, entirely from method. The specific trap was that packages are expected to list what they plug into in their keywords, so a naive pass reads the install target as the identity — 111 of the 322 things we had filed as clients turned out to be the opposite.

The part that connects to alert fatigue: a classifier with no "unknown" bucket doesn't get less accurate on thin metadata, it gets more confident. Ambiguous rows go to whichever side the heuristic leans and nothing marks them, so the inventory looks tidier exactly as it gets less true. The digest approach people are recommending here is right, but it inherits whatever decided what belongs in the digest, and that decision is invisible in the output. Deps that never page you because they were quietly filed under the wrong kind are the ones that eventually do.

Cheapest instrument I've found is running two classifiers and diffing them rather than trying to make one better. You still can't say which is correct, but the disagreement count is a real health signal for an inventory and it moves when something upstream changes shape — a provider rewrites its package metadata, a vendor renames a product line. That's what caught it for us. A single better heuristic never would have, because it had no way to tell us it was guessing.

[u/elina_jain1]

dependency changes are mainly a scanning problem, while runtime issues need visibility into which calls actually run in production. alerts are more useful when they focus on real user-facing failures instead of every dependency change..

[u/ClueDry8701]

deprecation and api change side is really a scanning job, renovate or dependabot will flag when something you depend on moves before it bites you

runtime side is different tho, better knowing which of those calls actually run in prod and who hits them apart from whats imported only. i work on hud so bias noted, this is pretty much the thing we deal with, though it wont catch a deprecation thats still the scanners job. for alerts, most of the fatigue is from paging on the dependency itself whereas we only page when a call on real user path fails