Tracking errors

LogSure keeps your apps' errors as issues: reports of the same error are grouped, scrubbed before they are stored, and shown with their stack, their release and where they happen. Send the errors your code catches, let the tracker catch the rest, and report from servers and native apps with the server key.

Errors you catch

The tracker gives the page logsure.error:

try {
  checkout();
} catch (err) {
  logsure.error(err, { step: 'checkout' });
}

The first argument is an Error (its type, message and stack are read) or a message. The second, optional, holds properties, as for events. These reports have the source manual.

Name the release and the environment on the script tag, and every report carries them:

<script defer data-app="example-shop" data-release="2.4.1" data-environment="production"
  src="/_care/script.js"></script>

What the tracker catches by itself

Each kind has its own switch in the app's settings (Settings › Apps, the app, Errors), and all are off until you turn them on. The tracker asks the server which are on when the first candidate happens, and the server checks again.

Switch	What it catches	Source
Uncaught errors	Uncaught errors and rejected promises	`uncaught`, `promise`
Console	`console.error` calls, which still log. The arguments become the message, and an Error among them gives the stack.	`console`
Network	`fetch` and `XMLHttpRequest` requests that fail or answer 5xx, such as `POST /api/checkout answered 503`	`network`
Network 4xx	With Network, 4xx answers too	`network`
Resources	Scripts, style sheets and images that do not load	`resource`

A network error records the method, the address without its query, the status and the time, never the body or the headers. A page sends at most 10 reports, each distinct error once. The app can also list messages to ignore.

From servers and native apps

Back-ends and apps post to /_care/error with the app's server key:

curl -sS -X POST 'https://logsure.example.com/_care/error' \
  -H "authorization: Bearer $LOGSURE_KEY" \
  -H 'content-type: application/json' \
  --data '{"message":"Card declined by the payment provider","type":"PaymentDeclined",
           "stack":"PaymentDeclined: Card declined…\n    at charge (/srv/shop/payments.js:88:11)",
           "release":"api-1.18.0","environment":"production","props":{"code":"card_declined"}}'

Required: message. Everything else is optional: type, a stack or frames (file, function, line, column, inApp), url, release, environment (production by default), props, fingerprint, handled and timestamp.
Traces: send traceId and spanId to link the report to its trace. Exceptions on OpenTelemetry spans and logs at ERROR are linked by themselves; see Tracing.
The answer is 202 whether the report was kept or dropped (automatic capture off, an ignored message, or past the daily cap, ERROR_DAILY_CAP, 10,000 by default).

Never send the server key from a browser. Pages use logsure.error.

Before anything is stored

Email addresses, tokens and keys, card-like numbers and URL query strings are removed from the message, the stack, the page and the properties. Stacks are cut at 16 KB and 50 frames.

Issues

An app's open errors: each issue with its type, message, the first frame of the app's own code, the release, a sparkline, events, users and when it was last seen.

Grouping: reports with the same type, the same message once numbers, IDs and quoted values are taken out, and the same top three frames of the app's own code (the file without its build hash, and the function) are one issue. A fingerprint replaces all of that.
The list: open, resolved or ignored issues, newest first, with filters by release, environment and source, and search. Each shows its events and users in the window and a sparkline.
One issue: how often and since when, the last 30 days, the latest occurrence with its frames (the app's own code marked) or its request, where it happens (pages, browsers, systems, devices, releases), its occurrences and its notes.
Triage: members resolve, ignore or reopen an issue and add notes. A resolved issue that happens again opens again with a note.
Alerts: a new or reopened issue rings the bell, calls the app's webhook and notifies the iPhone and Mac apps. Ignored issues stay quiet.

The same is in the API (errors), the terminal (:errors) and over MCP (list_errors, get_error, set_error_status, add_error_note, set_error_settings).