Configuration - Nuxt

Module options

Everything is set under the ray key in nuxt.config.ts; credentials are usually overridden with NUXT_RAY_* variables.

Environments

Every environment should report under an unambiguous name - production, staging, preview. The name is a column in the panel and a filter on the error list, so without it a production outage looks exactly like an error someone triggered in a test. Leave your local environment without credentials: with no token and no key the integration loads and stays silent, so you do not need a separate switch to turn it off.

What the server reports

The module registers a Nitro plugin on four hooks:

Transactions go out on afterResponse, once the reply has already reached the visitor - nothing is sent while they are waiting. createError({ statusCode: 404 }) and every other 4xx is a caller getting it wrong, not the application failing, so only 5xx codes are reported.

Transaction names

A transaction takes its name from the matched route (GET /orders/:id, not GET /orders/8123), so one route stays one row in the panel no matter how many identifiers passed through it.

Node, workers and the edge

The same code runs on Node and on workers: the event is read through both event.node.req and the Fetch Request shape, so a Cloudflare or Vercel Edge deployment needs no second code path.

Vue and JavaScript errors from the browser

Off by default:

ray: {
    browser: {
        enabled: true,
    },
}

That registers the Nitro route and the client plugin. The browser reports to your app, never to the panel: it holds no project key, and giving it one would publish it. The server forwards every report with its own key and fills in the envelope - environment, release, timestamp - so the browser never chooses which environment its errors land in.

Vue swallows component errors into its own handler, so window.onerror never sees them. That is why the plugin wires both Nuxt hooks: vue:error for render and lifecycle failures, app:error for a fatal boot.

The route answers 202 to everything - a valid report, a malformed one, one rejected by the rate limit - so a caller learns nothing about the guards. It drops bodies over 16 KB and allows twenty reports per address per minute. The browser-side collector caps itself too: one report per distinct error per page view, ten per page view by default, with ResizeObserver loop and cross-origin Script error. filtered out.

Reporting by hand

window.DockRay?.captureException(error);
window.DockRay?.captureMessage('Checkout step skipped');

Protecting the private key

The private key is a project secret, not an identifier. Keep it in environment variables, in a secrets manager or in the server configuration - never in the repository, in logs, in a screenshot or in code sent to the browser. One project can hold many keys, so production and staging should each get their own: either can be revoked on its own without interrupting the others. A suspicion that a key leaked is reason enough to revoke it and generate a new one.