If every failure of every check got its own line, after a month the list would be useless: one broken button would produce hundreds of entries. Issues solve this: identical errors are merged into one line with a history and a repeat count. Below is how it works and what to do with the statuses.
What an issue is
An issue is a check that failed during a run. Other routes do not get into this list: manual check results and verifications stay evidence but create no issues. The point is that an issue is something that happened on its own, without your participation, and needs attention.
An issue and a visual difference are different things
A visual difference does not get into this list. It is a snapshot’s divergence from the baseline — the page rendered differently than before. Such a divergence is neither an error nor a breakage: it waits for a human decision and lives in the Diff Viewing section. An issue is a failed check with a fingerprint; a visual difference has no fingerprint and never turns into an issue.
Whole-build failures stand separately: there, identical build failures are analyzed, not checks. That is the Build Failure Triage section.
Identical errors merge
Every issue has a fingerprint — a short identifying mark by which identical errors count as one. It is built from three things: the project, the rule and the error text with all random numbers and identifiers stripped. That is why “element #12 not found” and “element #48 not found” are one issue with a repeat count, not two different ones.
What an issue’s card shows: the latest snapshot, the element in question, the check’s message, the run it came from, how many times it repeated, and the whole history. Usually that is enough to understand the cause without opening the test itself.
Statuses
- Open — needs attention. Such issues are visible in the summary and counted in the global numbers.
- Resolved — you looked and fixed it. But careful: a resolved issue can come back.
- Ignored — you decided this is not a problem. Such an entry never reopens by itself.
When a resolved issue returns
A resolved issue reopens by itself in one case only: when the same error repeated in a new run. This is protection from “fixed and forgotten”: the edit was made, the check passed — great, but if the breakage comes back, the product speaks up about it again. A short-lived success will not mislead you.
An ignored issue never reopens — that was your decision, and the product respects it. Use this status deliberately: it suits messages that are known to be harmless, not for “hiding the extra noise”.
The issue list is available not only to people: it has an external key-authenticated access, used by coding agents. The cycle then looks like this: the agent reads the issues, fixes the site’s code, marks them resolved — and the next run confirms that everything is fine.
Next: how to hand issues to a coding agent — in the External API Access section.