nuxt-monitor

nuxt-monitor

Local-first error monitoring for Nuxt. No DSN, no account, no sourcemap upload.

Runs inside your app, stores errors in a SQLite file next to it, and reads sourcemaps off the disk they were built onto. Nothing leaves the machine.

Installation

npm install nuxt-monitor

yarn add nuxt-monitor

pnpm add nuxt-monitor

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['nuxt-monitor'],

  monitor: {
    auth: { password: process.env.MONITOR_PASSWORD },
  },
})

The dashboard is at /_monitor. It opens without a password in development; in production, without one configured it answers 404 — errors are still collected, so you can set one later and find them waiting.

Requires Node 22.13+ (node:sqlite) and Nuxt 4.

Features

• Both sides. A Nitro error hook catches every server path — handlers, plugins, cached functions, unhandled rejections — and a client plugin catches the browser, including errors after hydration.
• Stack traces resolved to source, with the failing line in context. Maps are read from disk, so they cannot drift out of sync with the build that produced the error, and they are never served to the public.
• Occurrences grouped into issues by side, type, normalised message and the first frame in your own code — so a message carrying an id does not become a thousand issues.
• Breakdown by browser, OS, device, release, route and session.
• Alerts to Slack, Telegram or a webhook on a new issue, a regression or an issue growing — with a per-issue cooldown, grouping and quiet hours, because the version without those is the version people mute on the first day.
• exception() for what does not throw. A payment that does not reconcile is worth an alert and never reaches an error handler. Reports carry a level and a named group, and a channel can subscribe to just one group.
• The bodies, not just the stack. The response body of a failing request is kept, and the request body if you ask for it — "Cannot read properties of undefined" is one bug or fifty depending on what was posted.
• What led up to it. Navigations, requests and clicks before a browser error, so the trail ends at the call that returned the wrong shape rather than at the component that choked on it.
• Redaction on collect. Authorization headers, cookies, passwords and tokens never reach the database, and request bodies are off by default.
• Endpoints apart from pages. /api/orders failing for every consumer and /checkout failing to render are both "a server error" and are not the same problem; the list separates them.
• Your data, gettable. npx monitor export to JSON or CSV, plus stats and purge for when the dashboard is not reachable.
• Bounded storage. One SQLite file, capped by age, count and bytes. If it cannot be opened, collection turns itself off and the app keeps serving.
• Or an external database. Point databaseUrl at PostgreSQL or MySQL when one file per process is not what you want.

Documentation

vad1ym.github.io/nuxt-monitor — or pnpm docs:dev to read it locally.

• Getting started
• Configuration
• Authentication
• Sourcemaps
• Notifications
• Reporting by hand
• CLI and export
• Deployment

Limitations

• One instance on SQLite. The file is per-process, so each replica has its own and you get a partial view behind a load balancer. An external database lifts this.
• Not for serverless on SQLite. An ephemeral filesystem loses everything when the instance goes away; an external database does not.
• No multi-year retention or one view across many apps.

It is for the case those tools handle badly: one app, one server, errors you want to read now, on infrastructure you already have.

License

MIT