Capture uncaught exceptions and emit a log message

[iblancasa]

Is your feature request related to a problem? Please describe.

Backend services frequently fail in ways that never become telemetry: uncaught exceptions and unhandled promise rejections. Unless users manually register process-level handlers or add a third-party error tracker, these failures produce no OpenTelemetry logs, which means:

• crashes and fatal errors are missing from observability backends
• incident timelines are incomplete (no “last error” record)
• teams lose the stacktrace context needed to triage production issues quickly
• error tracking experiences are inconsistent across services and languages.

Describe the solution you'd like

• When an application throws an uncaught exception or has an unhandled rejection, the SDK should emit a LogRecord that captures the exception details.
• The log should include the exception semantic convention attributes (exception.type, exception.message, exception.stacktrace) and a meaningful severity (e.g., FATAL for uncaught exceptions, ERROR for unhandled rejections). This can use the new Exceptions API Add log exception support to Logger API/SDK opentelemetry-js#6379
• The resulting log should be exported through the normal logs pipeline so it appears in the same backend alongside other logs.

Additional context

Capturing these exceptions as logs provides immediate value for error tracking, incident response, and troubleshooting by ensuring the last failure event is recorded in the OpenTelemetry pipeline. It also reduces the gap between tracing/logs and error tracking, giving a consistent experience across services without forcing each team to add bespoke handlers.

I will send a PR implementing this feature.

[pichlermarc]

@iblancasa - thanks for opening this issue. I agree that this is a good feature, but I disagree that the SDK should report unhandled exceptions like that directly. I think an instrumentation package should do that. I'd suggest creating such a package in the contrib repo of trying to fit it into an existing package there (@opentelemetry/instrumentation-runtime-node maybe?) - I'm therefore transferring the issue to the contrib repo.

Dependencies: open-telemetry/opentelemetry-js#6379

[iblancasa]

@pichlermarc ok. It's fine :D I was not 100% sure about where the functionality should live and tried with a prototype and look good. But if you think this can go better as a separate package... perfect! I will send a PR soon. Thank you.

[pichlermarc]

@iblancasa I think the runtime-node instrumentation is a good fit. Note that when adding a new instrumentation, we require folks to be component owners and maintain it going forward. If the feature fits, adding to an existing package is usually less overhead.

[iblancasa]

Great. I'm totally fine maintaining it.