Health

Two screens hold a site’s health: Performance for whether it is up and how fast it is, and, with data-errors on the tag, Errors for what it throws. The Errors screen appears in the navigation once the first error arrives.

Uptime

Turn on Uptime checks in Settings and Lynq fetches the site’s URL, the one under General, and records whether it answered and how long it took. Up means the site answered without an error; a slow answer still counts once it arrives, and an answer that never comes, an error status, or a name that does not resolve counts as down. The last 90 days of checks are kept.

The Uptime section at the top of Performance shows the latest check, the share of checks that were up over the last 90 days, the p75 response time in the range, and a strip with one bar per day: green when every check passed, amber or red by how long the day was down, grey before checks began. Hover a bar for the day’s numbers.

An incident opens when two checks in a row fail and closes at the next successful check, so one missed check never becomes one. The table under the strip lists the range’s incidents with when they started and ended, the reason (HTTP 502, timeout after 10s, a network error’s name), how many checks failed and how long it lasted. While an incident is open the status line says so, with how long it has been going.

A check is one request that identifies itself as Lynq-Uptime. It never counts as a visit, and it is not one of the crawlers the bots snippet reports. Checks are off unless you turn them on.

Errors

Add data-errors to the script tag and Lynq loads a small extra chunk that listens for uncaught JavaScript errors and unhandled promise rejections. Each one is reported with its message, the script and line it came from, and the first 4 KB of the stack. It is off unless you add the attribute.

<script defer src="https://lynq.byharsh.com/js/lynq.js" data-site="your-site.com" data-vitals data-errors></script>

What is never sent

Nothing from the page’s DOM, no form values, no variables. Query strings are removed from every URL in the message, the script name and the stack before storage, because a query string is where an email or a token ends up. Ten errors per page load, then the chunk goes quiet, so a loop that throws on every frame cannot flood your numbers or ours.

The list

The Errors screen groups occurrences by message and the line they came from, so the same error across pages and days is one row. A row leads with the error’s type and where it came from, the function and file, then the message, then the page it hits most often. Beside it: when it was last seen, how long it has been around, a trend over the range (New when it first appeared inside the last week, Ongoing otherwise), how many times it happened and how many sessions it hit. Most frequent first, and the range and filters of every other screen apply, so “errors on mobile in the last 24 hours” is two clicks.

Filter on a row narrows every screen to the sessions that hit it. The Pages table then shows what those people saw, and a journey shows what one of them did before it threw.

An error’s page

Select a row and the error gets a page of its own, with a link you can hand to whoever owns the code.

Occurrences per day (or hour, or week, following the range) shows whether it is getting worse.
Stack is the newest occurrence as frames: the function, the file and the position, your own code first and frames from other bundles folded behind one line. Raw shows the text exactly as the browser reported it.
Pages, Browsers and Operating systems say where it happens.
Sessions lists everyone it hit, newest first; each opens as a journey, and one link filters every screen to the same people.

Performance keeps one line, how many errors the range holds, that leads here.

Reporting a handled error

lynq.error(e) reports an error you caught yourself, so a try/catch that swallows a failure still shows up in the list. It takes an Error, a string or anything thrown, and works whether or not the tag has data-errors.

try {
  await saveDraft();
} catch (e) {
  lynq.error(e);
  showRetry();
}

A handled error is the same row as an uncaught one, grouped the same way, and counts against the same ten per page load.

How they are grouped

Two occurrences are one error when they have the same message and come from the same line. Numbers and ids in the message are ignored for grouping, so “Cannot find item 4821” and “item 4822” are one row, and so are chunk 412 and chunk 413; quoted names are not, so reading 'plan' and reading 'price' stay apart. The row shows the message exactly as it was reported.

Script error.

A script served from another origin reports only “Script error.” with no message or stack; that is the browser protecting the other site, not Lynq. Add crossorigin="anonymous" to that script tag, and have its server send Access-Control-Allow-Origin, and the details come through.

Where they are counted

Error rows live in the same table as pageviews and events, under your site’s retention, and never touch the visitor numbers: no count on the Overview moves because a page threw.

Notes Settings