Error Management
The Issues screen lists every unique JavaScript and PHP fault captured from your site. One row is one issue, not one occurrence: errors are grouped by a fingerprint computed from their type and their normalised message, so a broken template that fires ten thousand times is one row with a count, not ten thousand rows.
The list
Navigate to Dashboard → Issues.
Each row shows the message, the error type, the status, how many times it has been seen and how many visits it reached, when it was first and last seen, and a link to a recording of a session that hit it, where one exists.
Those two counts answer different questions and are worth reading together: ten thousand occurrences across four visits is one visitor's browser in a loop, while ten thousand across four thousand visits is something every customer is walking into.
| Filter | Options |
|---|---|
| Status | New / Investigating / Resolved / Ignored / Muted |
| Type | JavaScript / Asset / Console / Promise / Request / PHP |
| Severity | Notice / Warning / Error / Critical |
| Environment | Whatever your site reports — production, staging, … |
| Release | The builds this site has actually reported |
| Where in the code | Theme / Plugins / WordPress core / Elsewhere / No file named |
| Date range | Applies to when the issue was seen |
| Search | Message text |
The Type, Environment, Release and Where-in-the-code filters are built from your own data, and each option carries its count. A site that has only ever reported one release does not see a Release filter at all.
Narrowing to your own theme
Where in the code is the filter to reach for when the list is too noisy to work through. It says which part of a WordPress install each fault came out of:
| Value | What it means |
|---|---|
| Theme | wp-content/themes/… — your parent or child theme. Both read as "Theme": the difference is a directory name, and the question ("is this my own code?") has the same answer for either. |
| Plugins | wp-content/plugins/… or mu-plugins/… |
| WordPress core | wp-includes/… or wp-admin/… — jQuery lives here |
| Elsewhere | A file was named and it is none of the above: a third-party script on a CDN, a bundle a page builder wrote into uploads/, an inline script |
| No file named | The report named no file at all — a cross-origin script the browser refused to describe, a console.error with no stack, a PHP fault with no path |
Two things are worth knowing about how the value is decided. When the browser (or PHP) names the file the fault happened in, that file decides on its own. When it does not, the stack is read instead, and a theme frame anywhere in it wins over a plugin frame, which wins over a core one — because almost every WordPress stack passes through jQuery on its way out, and taking the innermost frame would file your theme's own bug under "WordPress core".
Nothing is being hidden from you by this: collection is unchanged. Every fault your site produces is still stored, and clearing the filter shows all of them again. The filter is a question you ask, not a setting that stops anything being recorded.
The filter appears once the values have been computed for your site. If you self-host and have
just upgraded, an administrator runs pnpm errors:classify once to label issues that predate the
feature.
Browser notices are hidden
Some reports are the browser's own behaviour rather than a fault anybody can fix: a
ResizeObserver loop notice, an iOS autofill internal, an autoplay refusal, a permission the
visitor declined. They are hidden from the list by default — and the number of them is always
printed at the bottom of the page, with a control to show them. Nothing is ever deleted.
Script error. is deliberately not hidden: it looks like noise and it is fixable, and the
issue page explains how.
Faults in StorePilot's own collector are excluded
A report whose stack runs entirely through StorePilot's own script is our defect, not your shop's — there is nothing you could change on your site to fix it. Those reports are kept out of the list, out of the CSV export, out of your plan's usage and out of alerts, and the number of them is printed at the bottom of the page so the list never silently shrinks. There is no control to show them, because there is no action to take: we see them on our side and they are never deleted.
A fault in your code that merely passes through our script on its way out — a request your theme makes failing inside our network wrapper, say — is still your issue and stays in the list.
Which issues you have already looked at
Every issue you have not opened is marked with a dot and a heavier title. Opening it clears the mark — from anywhere, including a link in an alert email.
The mark is yours, not your team's: a colleague reading an issue does not mark it read for you, and it follows your account rather than your browser, so the same issue reads the same way on your laptop and your phone.
Unseen in the toolbar narrows the list to what is left, Mark all as read clears the backlog in one press, and selecting rows offers Mark as read and Mark as unread — the second is how you put something back on your own queue.
New occurrences of an issue you have already read do not mark it unread again. A fault that happens every minute would otherwise be permanently unread, and the mark would stop meaning anything within a day.
Leads and Recordings carry the same mark, and it works the same way on both.
Statuses
| Status | Effect |
|---|---|
| New | Untriaged |
| Investigating | In progress — notifications unchanged |
| Resolved | Fixed. If it happens again it re-opens and notifies |
| Ignored | Acknowledged, not being worked on. Notifications stop |
| Muted | Silent. No notifications, even when it comes back |
Snooze is separate from status, and it is the one people miss. A flapping fault that keeps resolving and coming back will page you on every round trip; snoozing it until Monday stops the notifications without pretending it is fixed, so it stays in the triage queue where you can see it.
Select several rows with the checkboxes to change status or delete in bulk. Changing status in bulk needs the member role; deleting needs admin.
The issue page
It answers, top to bottom, the questions people arrive with.
Impact — how many people, how many visits, how many pages, and a bar per day so you can see whether it is getting worse. These are counts, never percentages of your traffic: errors and pageviews are not collected under identical rules (a site past its plan ceiling keeps reporting errors and stops reporting pageviews), so a ratio between them would sometimes describe your plan rather than your site. The window the figures cover is stated under them.
Carts at risk — what was in the baskets of the visits that hit it. Correlation, not proof.
Where in the code — the stack, resolved back to your own source if you have uploaded a source
map for that release. Some reports have no stack and never will — a file that failed to load, a
deliberate console.error, a cross-origin script the browser refuses to describe, a fault
reported by your PHP — and the page says which of those it is and what to do, rather than showing
you an empty box.
Where it happens — the busiest pages, and the browsers, devices and releases it was seen on.
Occurrences and Recordings — when exactly, and the sessions you can watch.
Automatic re-open, and regressions
When an issue is resolved or ignored and the same fingerprint arrives again, it re-opens: the
status goes back to new, the occurrence count restarts at 1 — you are counting this recurrence,
not adding to the one you already closed — and a notification fires.
That transition is also what records a regression. If the incoming report carries a release, the issue remembers which build brought it back, and the list badges it:
Regressed · v1.4.2
The badge is shown only while the issue is open again; re-resolve it and the badge goes. An issue that was already open and simply happened again is not a regression — it is the same open issue.
Releases
Three separate facts, once your builds report a release:
- Release — the build the latest occurrence came from. This moves as you deploy.
- First seen in — the build the first occurrence came from. Written once, never overwritten.
- Regressed in — the build a closed issue came back in.
Together they read as "introduced in v1.3.0, now on v1.4.2", which is usually the whole investigation.
Setting the release is your job, and there is no default. Inventing one would fill the column with a value that makes "which release introduced this" look answered when it is not.
- Any site: set
window.StorePilot = { release: 'v1.4.2' }before the StorePilot script tag. - WordPress: return it from the
storepilot_releasefilter — for example from your theme'sfunctions.php, reading whatever your build already writes.
The same string is what matches an uploaded source map, so a symbolicated stack trace depends on it being the build you actually shipped. See Source Maps.
The detail page
Opening an issue shows the full message and severity, where and when it occurred, the stack trace — symbolicated into your original source when a matching source map has been uploaded — the browser context captured at the time, and the sessions that hit it. Each linked session with a recording carries a link straight into the replay, seeked to the moment it fired.
Assigning and discussing
An issue has an owner and a thread.
The assignee pill in the header reads Unassigned or Assigned: [name], and the picker offers the members of the organization that owns this site — all of them, including viewers. An assignment to anyone outside that organization is refused by the server, not just hidden by the picker.
The Comments panel at the bottom of the page is the team thread. Notes are kept oldest-first and cannot be deleted once posted.
Both assigning and commenting need the member role — the same bar as changing status, because triage is why a member is invited in the first place. Reading the thread needs only view access.
A comment outlives its author's account. The author's address is copied onto the comment when it is written, so if that person later leaves and their account is deleted, the note stays and still says who wrote it.
Linking an issue to Jira, GitHub or Linear is deliberately not built.