feat(develop): document traceIgnoreStatusCodes

[lcian]

DESCRIBE YOUR PR

Documents the traceIgnoreStatusCodes option for SDKs.
This is a proposal on how to implement it.

This contrasts with the implementation in JS because there it's an option on httpIntegration.

However, to make this work for OTEL instrumentation too, we need to make it a client option (as in POTEL SDKs there might be no concept of OTEL "integration" to pass parameters to), and rely on the span attribute (because that's the only thing the SDK sees from the spans generated by OTEL instrumentation).

Another option in non-POTEL SDKs would be to implement it as an option on each integration, but this way to specify the option and implement it makes it consistent across SDKs (regardless of POTEL/non-POTEL).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
develop-docs	Ready	Preview	Comment	Sep 25, 2025 8:46am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
sentry-docs	Ignored	Preview		Sep 25, 2025 8:46am

[codecov]

Bundle Report

Changes will decrease total bundle size by 6 bytes (-0.0%) ⬇️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sentry-docs-client-array-push	10.13MB	-6 bytes (-0.0%) ⬇️

Affected Assets, Files, and Routes:

view changes for bundle: sentry-docs-client-array-push

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
static/chunks/pages/_app-*.js	-3 bytes	882.71kB	-0.0%
static/chunks/8321-*.js	-3 bytes	425.87kB	-0.0%
static/P4oHP6xEFs0X1_-*.js (New)	684 bytes	684 bytes	100.0% 🚀
static/P4oHP6xEFs0X1_-*.js (New)	77 bytes	77 bytes	100.0% 🚀
static/i0xHddP4CYDguQ0wVpiCU/_buildManifest.js (Deleted)	-684 bytes	0 bytes	-100.0% 🗑️
static/i0xHddP4CYDguQ0wVpiCU/_ssgManifest.js (Deleted)	-77 bytes	0 bytes	-100.0% 🗑️

[adinauer]

Mostly LGTM. Do we already know how we want to report this in client reports? Should it be event_processor or have a separate reason?

[lcian]

Mostly LGTM. Do we already know how we want to report this in client reports? Should it be event_processor or have a separate reason?

I think event_processor makes sense here as we already use it for things like ignoredTransactions.

[Lms24]

The JS Node SDKs already have an option on our server-side http integration (basically the place that starts traces for all incoming http requests in Node severs) which is called dropSpansForIncomingRequestStatusCodes. I think it makes sense to eventually lift this to a top-level init option with a better name.

However, one thing I would consider for traceIgnoreStatusCodes is that it should also accept an inclusive interval as input, for example something like:

traceIgnoreStatusCodes: [[401, 404], [301, 303], 305, 429]

This is a lot easier for users to handle than to expect them to write out the e.g. 35+ 4xx status codes. Instead, they'd simply define [[400, 499]].

WDYT?

final suggestions: I think a couple of examples for such options are always helpful in develop docs, especially if we're going with the interval syntax.

[Lms24]

we currently default to the following range of ignored status codes: [[401, 404], [301, 303], [305, 399]].

For example, users often complain about traced redirect responses for moved resources. Similarly getting permission denied errors/forbidden (401/403) for bots sending requests to protected endpoints is equally spammy as 404s. I think we want to be a bit more aggressive in terms of default values but happy go with slimmer minimum defaults if you/other reviewers prefer.

[lcian]

Overall it seems the default you propose makes sense.
Even if you get one of these and you don't trace it, you'll get an error/trace on the client that will tell you what happened (if there's a real bug and it's not a bot hitting the route, that is).
Just wondering if this has been released already, and if anyone complained about these new defaults?

[lcian]

Addressed all comments, thanks everyone.

[Lms24]

Thanks for addressing the suggestions, LGTM!