Health

The Health screen holds a site’s health: whether it is up, how fast it is, and, with data-errors on the tag, what it throws. The errors sections appear at the end of the screen 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.

Health opens on the Web Vitals, each p75 with the share of visits that were good, needs work and poor under it (a p75 alone hides the visits that were poor), then the range on one axis: a strip along the top with one cell per day, amber when an incident under an hour fell on it and red for a longer one, LCP p75 per device drawn beneath against the 2.5 s line, incidents shaded where they fell, and the site’s notes as pins, so the day the site was down is visibly the day it was slow. The Uptime section under it shows the latest check, the share of checks that were up over the last 90 days, the p75 response time in the range, and its own strip of the last 90 days: green when every check passed, amber or red by how long the day was down, grey before checks began. Hover a cell 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 reporting stops for that page load, so a loop that throws on every frame cannot flood your numbers or ours.

When each error was seen

The errors part of Health opens with the most frequent errors drawn on the range, one bar each from the first time it was seen to the last, the longest-lived at the top. An error first seen in the last week is drawn in the accent, so a new one stands out from the ones that have been there all along. A bar opens the error’s page.

The list

The list 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, 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.

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 reported the same way 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

Errors are kept under your site’s retention and never touch the visitor numbers: no count on the Overview moves because a page threw.

Notes Accessibility