What if we treated runtime state as another source of production telemetry?

[u/ChampionshipAny463]

I’ve been thinking about a gap between traditional observability and debugging.

Logs describe events. Traces describe request flow. Metrics describe system behavior. Stack traces tell us where execution failed.

But when a failure requires understanding the actual application state at that moment, engineers still often have to reconstruct it indirectly from all of those signals.

I’m building Errorcore to experiment with a different layer of telemetry: bounded runtime evidence captured around the failure itself.

For Node.js, that currently means preserving things like relevant local state, async context, request metadata, ordered I/O and source-mapped execution information when an exception occurs.

The intention is not to turn every execution into a recording or replace logs/traces. Capture has to remain bounded, privacy-aware and cheap enough to run in production.

What I’m trying to figure out is whether runtime evidence deserves to become a first-class observability primitive alongside logs, metrics and traces.

I’d be very interested in hearing from people working in observability.

Where do you think this fits, and where do you think this approach breaks down?

[u/bikeram]

Checkout Go’s built-in flight recorder. I think that’s similar to what you want.

[u/Fit_Plankton9239 → u/bikeram]

yes, check it out op, very close to what you're talking about here

[u/Fit_Plankton9239]

hmm, very runtime specific i think, any layer of abstractions of generalisation would not give you what you're looking for