| title | sidebar_order | supported | description | redirect_from | ||
|---|---|---|---|---|---|---|
Automatic Instrumentation |
10 |
|
Learn what transactions are captured after tracing is enabled. |
|
Capturing transactions requires that you first set up tracing in your app if you haven't already.
<PlatformSection supported={["javascript.nextjs"]} notSupported={["javascript"]}>
Though the BrowserTracing integration is automatically enabled in @sentry/nextjs, in order to customize its options you must include it in your Sentry.init in sentry.client.config.js:
import * as Sentry from "@sentry/nextjs";
Sentry.init({
dsn: "___PUBLIC_DSN___",
integrations: [
new Sentry.BrowserTracing({
// custom options
}),
],
tracesSampleRate: 1.0,
});Supported options:
A list of strings and regular expressions. The JavaScript SDK will attach the sentry-trace and baggage headers to all outgoing XHR/fetch requests whose destination contains a string in the list or matches a regex in the list. If your frontend is making requests to a different domain, you'll need to add it there to propagate the sentry-trace and baggage headers to the backend services, which is required to link transactions together as part of a single trace.
The tracingOrigins option matches against the whole request URL, not just the domain. Using stricter regex to match certain parts of the URL ensures that requests do not unnecessarily have the additional headers attached.
The default value of tracingOrigins is ['localhost', /^\//]. This means that by default, tracing headers are only attached to requests that contain localhost in their URL or requests whose URL starts with a '/' (for example GET /api/v1/users).
You will need to configure your web server CORS to allow the sentry-trace and baggage headers. The configuration might look like "Access-Control-Allow-Headers: sentry-trace" and "Access-Control-Allow-Headers: baggage", but it depends on your set up. If you do not allow the two headers, the request might be blocked.
beforeNavigate is called at the start of every pageload or navigation transaction, and is passed an object containing the data with the transaction will be started. Using beforeNavigate gives you the option to modify that data, or drop the transaction entirely by returning undefined.
This function can be used to filter out unwanted spans such as XHR's running health checks or something similar. Whether specified or not, shouldCreateSpanForRequest filters out everything but what was defined in tracingOrigins.
The idle time, measured in ms, to wait until the transaction will be finished, if there are no unfinished spans. The transaction will use the end timestamp of the last finished span as the endtime for the transaction.
The default is 1000.
The maximum duration of the transaction, measured in ms. If the transaction duration hits the finalTimeout value, it will be finished.
The default is 30000.
The time, measured in ms, one heartbeat takes. If no new spans were started or no open spans finished within three heartbeats, the transaction will be finished. The heartbeat count restarts whenever a new span is created or an open span is finished.
The default is 5000.
This flag enables or disables creation of navigation transaction on history changes.
The default is true.
This flag enables or disables creation of pageload transaction on first pageload.
The default is true.
This option flags transactions when tabs are moved to the background with "cancelled". Because browser background tab timing is not suited for precise measurements of operations and can affect your statistics in nondeterministic ways, we recommend that this option be enabled.
The default is true.
This is an object containing experimental flags for features that haven't yet landed in a new major version and might include breaking changes.
The default is
{
enableLongTasks: true
}
This experimental option determines whether spans for long tasks automatically get created.
The default is true.