Next.js Pages Router `getServerSideProps` is wrapped in `@sentry/nextjs` v10, but no `function.nextjs` spans are emitted, so Slow SSR widget stays empty

[Paulus90]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

10.55.0

Framework Version

15.5.18

Link to Sentry event

No response

Reproduction Example/SDK Setup

We are using a Next.js Pages Router app with SSR via getServerSideProps on many routes.

Versions:

• next: 15.5.18
• @sentry/nextjs: 10.55.0

Sentry setup:

• withSentryConfig(...) is enabled in next.config.js
• webpack.autoInstrumentServerFunctions: true is explicitly enabled
• instrumentation.ts exists and imports sentry.server.config / sentry.edge.config
• Sentry.init(...) is active on the server with tracesSampleRate > 0
• Server-side data is definitely reaching Sentry already (http.server, middleware, and related spans are visible)

Important verification from our side:

• We inspected the compiled production output and confirmed that page handlers are wrapped with wrapGetServerSidePropsWithSentry(...)
• So the build-time wrapping appears to be active
• However, we still see no function.nextjs spans in Sentry

Steps to Reproduce

1. Create or use a Next.js 15 Pages Router app.
2. Install @sentry/nextjs@10.x.
3. Configure Sentry with:
   • withSentryConfig(...)
   • instrumentation.ts
   • server tracing enabled
   • webpack.autoInstrumentServerFunctions: true
4. Add one or more Pages Router routes using getServerSideProps.
5. Build/run the app and hit SSR pages.
6. Inspect incoming spans/traces in Sentry and check the Slow SSR widget.

Expected Result

One of the following should happen consistently:

• getServerSideProps instrumentation emits SSR spans recognizable by the Slow SSR widget, including function.nextjs if that is still the expected span op

or

• the documentation/widget behavior should clearly reflect the new span model if function.nextjs is no longer expected in @sentry/nextjs v10

In short: a correctly instrumented Pages Router SSR app should populate the Slow SSR widget or have documented replacement behavior.

Actual Result

• Traces and server-side spans are sent successfully
• http.server and other server spans are visible
• function.nextjs spans never appear
• The Slow SSR widget remains empty

Additionally, after inspecting the installed SDK behavior, it appears that wrapGetServerSidePropsWithSentry(...) delegates to withTracedServerSideDataFetcher(...), and that helper seems to set metadata / transaction naming / trace propagation, but does not appear to create a dedicated SSR child span with op: "function.nextjs"

That matches what we see in Sentry:

• wrapping exists
• tracing exists
• but the widget-relevant SSR spans do not exist

Additional Context

This may be one of two things:

1. A bug/regression in @sentry/nextjs Pages Router SSR instrumentation for v10 / Next.js 15

or

2. A mismatch between current SDK span behavior and the Slow SSR widget, which may still depend on an older span shape/op such as function.nextjs

If function.nextjs is no longer intended in this SDK/version, could you clarify:

• what span(s) should replace it
• whether the Slow SSR widget supports that new model
• whether the docs should be updated for Pages Router SSR on modern Next.js / Sentry versions

Priority

No response

[linear-code]

JS-2759

[isaacs]

Thanks for reporting this!

So, first of all, your configuration is correct, and as far as I can tell, this isn't a problem on your end. What's going on here is that the op: "function.nextjs" span is currently emitted only for App Router server components/layouts in v10.

I will need to check internally to see if this was an intentional change in v10, or if it's a regression. It does seem like either that span should be brought back for non-App Router components, or the Pages Router SSR docs need to be updated so that you don't expect it (and possibly, call it out as being an intentional change in v10, along with the reasoning.)