Error Tracking

Capture client and server errors

Browser errors are reported by the web SDK. Server errors in Nitro routes are reported by @faststats/nitro.

Browser Errors

Add the error-tracking extension to capture uncaught errors and unhandled promise rejections. The tracker batches them and drops noise from browser extensions automatically.

import { errorTracking } from "@faststats/react/error";

<Analytics siteKey="your_site_key" extensions={[errorTracking()]} />;
nuxt.config.ts
faststats: {
	siteKey: "your_site_key",
	extensions: { errorTracking: true },
}
import { init } from "@faststats/web";
import { errorTracking } from "@faststats/web/error";

init({
	siteKey: "your_site_key",
	extensions: [errorTracking()],
});

Errors are grouped by their type and message so the same error from many visitors does not flood your dashboard. Identical errors within a batch are counted instead of repeated.

Options

OptionTypeDefaultDescription
flushIntervalnumber5000Milliseconds between batch uploads
maxQueueSizenumber50Errors held before an early flush and kept while offline
errorTracking({ flushInterval: 10_000, maxQueueSize: 100 });

In Nuxt, pass the same object as extensions.errorTracking.

Batches are also flushed when the page is hidden. If the collector is unreachable the queue is capped at maxQueueSize and the oldest errors are dropped. A batch the collector rejects is not retried.

Report Errors by Hand

When you catch an error yourself, send it through the running client. An error-tracking extension must be active to receive the report.

import { reportError } from "@faststats/web";

try {
	doRiskyThing();
} catch (error) {
	reportError(error as Error);
}

In React, get the client with useAnalytics() and call analytics?.reportError(error). In Nuxt, call $faststats.reportError(error).

In Nuxt, enabling extensions.errorTracking also hooks the module into the Vue error handler, so component errors are reported without extra code.

Server Errors with Nitro

If you run Nitro, either standalone or through Nuxt, you can report errors thrown in server routes with @faststats/nitro. The package ships a plugin for Nitro v2 and one for Nitro v3.

npm install @faststats/nitro

nuxt.config.ts
import { createRequire } from "node:module";

const require = createRequire(import.meta.url);
const errorTrackingPlugin = require.resolve("@faststats/nitro/v2");

export default defineNuxtConfig({
	nitro: {
		plugins: [errorTrackingPlugin],
	},
});
nitro.config.ts
export default defineNitroConfig({
	plugins: ["@faststats/nitro/v2"],
});

Use the /v3 import instead when you are on Nitro v3.

Server Configuration

The server plugin reads its settings from environment variables. The token is a project token, not the browser site key, so keep it on the server only.

VariableDefaultDescription
FASTSTATS_TOKENrequiredProject token used to authorize reports
FASTSTATS_ERROR_ENDPOINThttps://metrics.faststats.dev/v1/errorWhere server errors are sent
FASTSTATS_BUILD_IDnoneTags errors with a build for source maps
FASTSTATS_SESSION_IDnoneSession ID attached to every report
FASTSTATS_DEBUG0Set to 1 to log reporter activity
.env
FASTSTATS_TOKEN=your_project_token

If FASTSTATS_TOKEN is not set the plugin stays silent and skips reporting, so it is safe to leave installed in environments without a token.

Custom Configuration

You can also create a plugin with explicit options instead of environment variables. This lets you attach extra context to every error.

server/plugins/faststats.ts
import { createFaststatsNitroPluginV2 } from "@faststats/nitro/v2";

export default createFaststatsNitroPluginV2({
	token: process.env.FASTSTATS_TOKEN,
	getContext: ({ path }) => ({ route: path }),
});

getContext receives the error, the request path, and Nitro’s error tags. Use createFaststatsNitroPluginV3 from @faststats/nitro/v3 on Nitro v3.

OptionDefaultDescription
tokenenvProject token
errorEndpointenvWhere server errors are sent
buildIdenvBuild ID for source maps
sessionIdenvSession ID attached to every report
debugfalseLogs reporter activity
flushIntervalMs5000Milliseconds between batch uploads
maxBatchHashes50Distinct errors held before an early flush
circuitBreakerFailures5Consecutive failed sends before reporting pauses
circuitBreakerPauseMs60000How long reporting pauses once the breaker opens
getContextnoneReturns extra context attached to each error

The reporter batches errors, retries failed sends and opens a short circuit breaker after repeated failures so a broken endpoint never slows your server down.