Check’d
Start free

Product

All featuresProduction monitoringSession replayAI explain and fixImport API docsJourneys
DevelopersPricingFree site scanChangelogSign in

See the errors your users hit, next to what your tests found.

Add one script tag or an npm package. Check’d captures errors, failed requests and slow pages from your live app, groups them by root cause, and puts them in the same inbox as your test runs, website scans and load tests.

Start freeRead the install guide

On every plan, including Free. Private by default: no typed values, bodies or query strings.

Three steps to your first issue

Set up takes a few minutes. The setup page sends a test event and waits for your first real one.

  1. Step 1: Create an ingest key

    In your project, open Settings, Production monitoring. The public key can only send events, so it is safe in page source.

  2. Step 2: Add the SDK

    A script tag in the head of every page, npm install checkd-browser for bundled apps, or checkd-node on the server.

  3. Step 3: Tag your releases

    Set the release on the SDK or register deploys from CI, so every issue knows the version it first appeared in.

What it captures, and what it leaves out

Enough to find and fix the problem, and nothing your users typed.
  • Errors with stack traces, from uncaught exceptions, unhandled rejections and captureError.
  • Failed requests: method, URL, status and duration of fetch and XHR calls that fail or return a 5xx. Never bodies or headers.
  • Slow pages: poor Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, server response time and load time.
  • Breadcrumbs: the last 30 clicks, page changes and requests before each error, recorded as elements and routes, not values.
  • Context: release, environment, browser, system, device and an anonymous visitor id, plus your user id when you call identify.

  • Never read

    Typed values. A click on a field is recorded as the field, not what was in it.

  • Stripped

    Query strings and fragments, from every URL and from URLs inside error messages.

  • Never sent

    Request and response bodies and headers.

  • Scrubbed twice

    Bearer tokens, password= and token= values, JWTs and card numbers, removed again on our servers.

One inbox for production and tests

Occurrences of the same problem become one issue, so ten thousand identical errors are one line. Production issues sit next to what your test runs, scans and load tests found, highest impact first.
  • Grouped by error type, a cleaned message and the top frames of your own code; failed requests by route and status; slow pages by route and metric.
  • Users affected, occurrences, first and last seen, and the browsers, systems and releases on every issue, with a 30 day chart.
  • Statuses (new, investigating, resolved, ignored, regressed), owners, comments and bulk actions.

Releases, regressions and alerts

Know which deploy broke something, and hear about it before your users write in.

  • First seen in a release

    Set release on the SDK and every issue records the version it first appeared in. Register deploys from CI with the releases API.

  • Regressions

    Resolve an issue in a release. If it comes back in a newer one, it is marked regressed. Errors from old tabs still running an older release do not count.

  • Alerts by email or Slack

    When a new issue appears, a resolved one comes back, or an issue spikes past the threshold you set for the project.

See what happened before the error

Turn on session replay and the issue page plays back the minute before the error, with every input masked in the browser. How session replay works.
  • Records around errors by default, so quiet sessions upload nothing.
  • Error, click and request markers on the timeline.
  • Save a real session as a journey test.

Then ask what is wrong

Explain with AI reads the issue (never user ids, IP addresses or query strings) and, with GitHub connected, your code at the matching release. It says what is broken, why, where to look and how to fix it, and can open a fix pull request. About AI explain and fix.
Install the SDKPrivacy details

Questions people ask

How the SDKs behave, what they send and what it costs.

Ask support something else
What does the SDK capture?

Uncaught errors and unhandled promise rejections with stack traces, fetch and XHR calls that fail or return a 5xx, poor Web Vitals and slow loads, the last clicks, page changes and requests before each error, and the release, environment, browser and device. Anything else only when you call captureError or track.

What does it never capture?

Typed values, request and response bodies and headers. Query strings and fragments are removed from every URL, including inside error messages, and tokens, passwords, JWTs and card numbers are scrubbed again on our servers. Emails passed to identify are hashed in the browser unless you turn that off.

How big is the browser SDK?

The script tag is under 10 KB gzipped with no dependencies, and it sends nothing until an error, a failed request or a slow page happens, or you call track. Session replay is a separate script that only loads when you turn it on.

Does it work with my stack?

The browser SDK works in any site through a script tag, or from npm in React, Next.js, Vue and other bundlers. The Node.js SDK captures server errors and has helpers for Express, Fastify and AdonisJS. Anything else can post to the ingest API.

Is monitoring on the free plan?

Yes. Production monitoring and the issue inbox are on every plan. Paid plans raise the event allowance and how long occurrences are kept; the app shows your current numbers on the Plan and usage page.

What happens when I go over my allowance?

Events past the month’s allowance are dropped and counted on your Plan and usage page. Your app never sees an error, and nothing is billed for the overflow.

Works with the rest of Check’d

Watch production on the free plan

Add the SDK to one project and see your first issue in minutes. No card needed.

Start freeScan a site, no account needed