Request: Add configuration option to capture 302 redirect transactions

Problem Statement

The Sentry Node SDK currently drops HTTP transactions with 302 status codes by default (introduced in v9.x via #16972). While this reduces noise for most applications, it creates a significant blind spot for SSO (Single Sign-On) applications and other authentication services where 302 redirects represent the primary and most critical code paths.
Use Case
I'm running an SSO authentication API where the main flow is:

Receive SAML assertion at POST /auth/assert
Validate credentials (includes multiple database queries)
Create session and redirect user (302) to the target application
The problem: Despite enabling profiling with profilesSampleRate: 1.0, no profiling data is captured for these critical routes because they return 302 status codes. The logs show:
[Profiling] started profiling transaction: POST /auth/assert
[Profiling] stopped profiling of transaction: POST /auth/assert
Dropping transaction due to status code 302
Event processor "Http" dropped event
The profiling data is being collected but then immediately discarded.

Solution Brainstorm

Proposed Solution
Add a configuration option to control which status codes are filtered, similar to how 300 and 304 were re-enabled in v10.13.0 (#17686):
javascript

Sentry.init({
  dsn: "...",
  integrations: [
    nodeProfilingIntegration(),
    Sentry.httpIntegration({
      // Option 1: Capture specific status codes
      captureStatusCodes: [200, 201, 300, 301, 302, 303, 307, 308, 400, 500],
      
      // OR Option 2: Disable status code filtering entirely
      filterStatusCodes: false,
    }),
  ],
  tracesSampleRate: 1.0,
  profilesSampleRate: 1.0,
});

Workarounds Attempted

beforeSendTransaction hook - Not called because the Http event processor drops the transaction first
Removing the Http integration - Auto-instrumentation still creates and drops transactions
Manual transaction creation with startSpanManual - Creates duplicate transactions that both get dropped
Downgrading to v7 - Not viable due to Node.js version compatibility issues with @sentry/profiling-node

Additional Context

Impact
This affects any application where redirects are business-critical:
• SSO/authentication services (SAML, OAuth, OIDC)
• API gateways that redirect to different services
• URL shorteners
• Applications implementing the Post/Redirect/Get pattern
For these applications, the most performance-critical code paths produce zero profiling data.
Additional Context
• Version: @sentry/node@10.26.0 and @sentry/profiling-node@10.26.0
• The issue exists in all v9.x and v10.x versions
• Related: #17686 (which added 300/304 support, showing there's precedent for making redirect status codes configurable)
Example Debug Output
[Tracing] Starting sampled root span
op: http.server
name: POST /auth/assert
[Profiling] started profiling transaction: POST /auth/assert
... (database queries and business logic spans) ...
[Profiling] stopped profiling of transaction: POST /auth/assert
Dropping transaction due to status code 302
Event processor "Http" dropped event
An event processor returned null, will not send event.
Would appreciate any guidance on how to capture these transactions, or consideration for adding this configuration option in a future release. Thank you!

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

JS-1297

@peter-ecp

Hey @peter-ecp, thanks for writing in.

You should be able to set dropSpansForIncomingRequestStatusCodes of the http integration, something like:

Sentry.init({
   dsn: '...',
   integrations: [
      Sentry.httpIntegration({
		 // Explicitly exclude `302` from the range
         dropSpansForIncomingRequestStatusCodes: [[401, 404], [301, 301], [303, 303], [305, 399]],
       }),
   ]
})

Does that work for you?

feat(js): Document missing options for http integration (#15815)

Thanks for the suggestion. Unfortunately, dropSpansForIncomingRequestStatusCodes doesn't solve the issue in my case. The problem is that my SSO authentication routes use callback-based async patterns with passport.authenticate(), and the response is sent via a chained middleware handler: typescript: router.post('/assert', (req, res, next) => { passport.authenticate('saml2', (err, user, info) => { // Async callback - work happens here req.user = user; next(); // Passes to next middleware })(req, res, next); }, AuthController.loginUser); // This sends the 302 redirect When using automatic HTTP integration, the transaction finishes as soon as the route handler returns (synchronously), which happens before the passport.authenticate() callback executes. This results in: * Transaction ends immediately (only 1 span exported) * All database queries happen after transaction is closed (not captured) * Profile data is orphaned (null profile error) With manual instrumentation using Sentry.startSpan(), I successfully capture all database spans and the transaction is sent, but the profiler doesn't attach profile data to manually created spans - I get the "profiler returned null profile" error. Is there a way to make CPU profiling work with manual spans, or do I need to refactor my routes to async/await patterns for automatic instrumentation to work properly? Thanks, Peter

…

________________________________ From: Andrei ***@***.***> Sent: Monday, December 15, 2025 12:35 AM To: getsentry/sentry-javascript ***@***.***> Cc: Peter Terhorst ***@***.***>; Mention ***@***.***> Subject: Re: [getsentry/sentry-javascript] Request: Add configuration option to capture 302 redirect transactions (Issue #18490) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [Caution] This email originated from outside of the organization. Do not open links or attachments unless you recognize the sender and know the content is safe. [https://avatars.githubusercontent.com/u/168741329?s=20&v=4]andreiborza left a comment (getsentry/sentry-javascript#18490)<#18490 (comment)> Hey @peter-ecp<https://github.com/peter-ecp>, thanks for writing in. You should be able to set dropSpansForIncomingRequestStatusCodes of the http integration, something like: Sentry.init({ dsn: '...', integrations: [ Sentry.httpIntegration({ dropSpansForIncomingRequestStatusCodes: [[401, 404], [301, 301], [303, 303], [305, 399]], }), ] }) Does that work for you? — Reply to this email directly, view it on GitHub<#18490 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BL7FJ3JNTD72XBPP7QKKY7T4BZXGTAVCNFSM6AAAAACO5B4P5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNJUGQZDINRUGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

Should I see profiling data appear immediately after app startup, or only after certain conditions?

In manual mode (default) the profiling data will only appear once you start profiling manually. In trace mode, the data will appear immediately in 60 second intervals, when there is a span.

Are there additional log messages I should look for that indicate profiles are being sent?

Profile starting/stopping:

[Profiling] starting profiling chunk: <chunk_id>[Profiling] started profiling transaction: <description>
[Profiling] Stopping profiling chunk: <chunk_id>[Profiling] stopped profiling of transaction: <description>

Profile sending:

[Profiling] Sending profile chunk <chunk_id>.[Profiling] Profile chunk <chunk_id> sent to Sentry.

Issues to watch for:

[Profiling] Discarding profile because it contains less than 2 samples
[Profiling] No transport available to send profile chunk.
[Profiling] Profile session not sampled, no-op.
[Profiling] Discarding profile because it contains less than 2 samples
[Profiling] No transport available to send profile chunk.
[Profiling] Profile session not sampled, no-op.

Does continuous profiling require the HTTP integration to be enabled?

In manual mode, you don't need it as it does not depend on spans. But in trace mode, tracing (and the integration) needs to be enabled as profiles are automatically created based on spans.

Is continuous profiling available on all Sentry plans?

Yes, on AM2 continues profiling consumes the on-demand quota. On AM3, it consumes the PAYG quota. And the consumption is shown in the stats page under Continuous Profile Hours.

Could removing the HTTP integration affect profile upload?

No it won't affect the upload.

Can you maybe share a link to your Sentry project so I can take a look in the admin dashboard? Feel free to also send me an email (sigrid[dot]huemer[at]sentry[dot]io).

And one thing I also noticed: You set profileLifecycle: 'trace' in your config. And you still get the log that the mode is trace?

As the issue derailed a bit - it was initially about 302 redirects and now it's more about profiling. Am I right, that those are your issues:

Spans should be created for 302 redirects
Continuous profiling data is not shown in Sentry with "Failed to fetch profiles"

Hi, thanks for following up by e-mail, I will continue the conversation here to keep everyone involved.

I am not able to open your project link (Cannot be reached DNS_PROBE_FINISHED_NXDOMAIN) and your Sentry project seems self-hosted. It could be that you are still running an old version, where viewing continuous profiles is not yet supported (you should see the version and commit hash at the bottom left in the Sentry UI).

Also, consider opening an issue for self-hosted: https://develop.sentry.dev/self-hosted/support/

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you remove the label Waiting for: Community, I will leave it alone ... forever!

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

Navigation Menu

Repository navigation

Request: Add configuration option to capture 302 redirect transactions #18490

Problem Statement

Solution Brainstorm

Additional Context

Priority

14 remaining items

Should I see profiling data appear immediately after app startup, or only after certain conditions?

Are there additional log messages I should look for that indicate profiles are being sent?

Does continuous profiling require the HTTP integration to be enabled?

Is continuous profiling available on all Sentry plans?

Could removing the HTTP integration affect profile upload?

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Request: Add configuration option to capture 302 redirect transactions #18490

Description

Problem Statement

Solution Brainstorm

Additional Context

Priority

Activity

linear commented on Dec 13, 2025

andreiborza commented on Dec 15, 2025

peter-ecp commented on Dec 16, 2025

14 remaining items

peter-ecp commented on Dec 18, 2025

s1gr1d commented on Dec 19, 2025

Should I see profiling data appear immediately after app startup, or only after certain conditions?

Are there additional log messages I should look for that indicate profiles are being sent?

Does continuous profiling require the HTTP integration to be enabled?

Is continuous profiling available on all Sentry plans?

Could removing the HTTP integration affect profile upload?

s1gr1d commented on Dec 19, 2025

s1gr1d commented on Dec 23, 2025

getsantry commented on Jan 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions