Verification and common problems - Nuxt

A controlled test event

export default defineEventHandler(() => {
    throw createError({ statusCode: 500, statusMessage: 'DockRay control error' });
});

Visit this route once and remove it right after the test succeeds. The entry should appear in the panel under Errors for the project the token points at.

Common problems

Credentials in the wrong part of the configuration

The token and key must land in the private half of the runtime config - through NUXT_RAY_TOKEN/NUXT_RAY_PRIVATE_KEY, or directly under the ray key in nuxt.config.ts. Placed under runtimeConfig.public.ray they end up in the client bundle - the same risk as a Next.js key with a NEXT_PUBLIC_ prefix.

404 errors do not show up in the panel

That is by design. Only 5xx codes are reported - createError({ statusCode: 404 }) and every other 4xx is a normal outcome, not a failure.

A Vue component error does not show up in the panel

Check whether browser.enabled is on and whether the page actually loaded the client plugin - Vue swallows component errors into its own handler, so without the vue:error/app:error hooks wired an error never reaches window.onerror, and from there the collector.

Transactions are missing despite a correct setup

Two independent causes: tracesSampleRate at 0, or the path matches one of the ignorePaths entries (by default /_nuxt, /__nuxt, /health, /metrics) and is skipped on purpose.

JavaScript errors from the browser do not arrive

The Nitro route only exists if browser.enabled was set at build time - turning it on with an environment variable at runtime alone is not enough, the module needs to know during setup(). Also check whether the server has NUXT_RAY_TOKEN and NUXT_RAY_PRIVATE_KEY set: the route still answers 202 either way, it just forwards nothing.

A worker deployment (Cloudflare) does not report

The module reads the event through the same path on Node and on workers, so no second code path is needed - if nothing still arrives, check whether the NUXT_RAY_* variables are actually available in that specific deployment's environment, not just locally.

One error splits into many entries

The panel groups by the fingerprint sha256(project token + type + message). An order or user identifier pasted into the exception message splits one error into a thousand rows.

The panel answers 200 but there is no event

A 200 {"success": false} response means the account has used up its monthly error quota. The integration does not treat that as a failure - and rightly so. You can see the quota on the account dashboard; until the end of the month it is counted from recorded usage, so deleting errors does not reset it.

Still not working

Work through the troubleshooting checklist, and if that does not help, write to us. Include the project name, the integration version and roughly when you ran the test: it shortens the way to an answer.