Issues

An issue is a problem with your site, tracked over time. It opens when something starts failing, stays open while it keeps failing, and resolves when it stops.

The alternative, used by most monitoring, is to report the difference between two runs. That fires once and then goes quiet, so a header that broke on Monday is still broken on Friday while the alerts report nothing. It also never records the fix.

The lifecycle

Open. A check starts failing. The issue records what is wrong, what to do about it, and when it was first seen.

Still open. Tomorrow's check fails the same way. The issue is updated, not duplicated, and its age keeps counting. You are not emailed again, because nothing changed.

Resolved. The check passes again. The issue closes with a timestamp, and appears under Fixed recently.

Recurring. The same problem coming back next month opens a new issue with its own timeline, rather than quietly reopening the old one. You keep the history of both.

Alerts

You are emailed when the list of open issues changes: something opened, something closed, or both. Not when a check merely confirms yesterday.

One message per run, not one per issue. A platform update that breaks four things at once is a single event to the reader, and four separate emails would train them to filter the alerts.

Resolutions are included as well as failures.

Every alert is also recorded in the app, under the bell in the top bar. Email can be switched off from your profile. The in-app record cannot, so an account that has filtered the email still has a record of what changed.

An inconclusive check changes nothing

A rate limit is not a repair. Resolving issues from an incomplete run would mark every problem on the site as fixed, so the issue stays open instead. A stale issue is preferable to reporting a site as healthy at the moment visibility was lost.