Self-Healing
When someone on your team hits a bug — a crashed page, a failed action — CartonCrew reports it automatically so a fix can be proposed. You don’t have to file anything; the broken moment becomes the bug report.
Who this is for: every member benefits. There is nothing to switch on.
What it does (and doesn’t)
- It is always on, for every organization, and there is no setting. An earlier version of this page described a Self-Healing card in Settings with a Turn on / Turn off button. That card is gone: capture is a core capability rather than a feature, and what protects your data is the scrubbing below, not an opt-out.
- What is captured: crashes in the admin app, server failures behind an error message you see (an AI or payment provider being unavailable, say), and errors on your public website.
- What is deliberately NOT captured: everyday refusals that are working as
intended — a form you filled in wrongly, a page your role cannot open, a
sign-in that has expired. Those are not defects, and recording them would bury
the ones that are. The exception is a small, named set of failures that can
only mean something is misconfigured on our side (a domain that no longer maps
to your organization, an upload the app and the server disagree about); those
are recorded even though they look like ordinary refusals to you. A visit to
an address that was never an organization’s (the bare
cartoncrew.onlineapex, a deployment preview URL) is not one of those — nothing there can be misconfigured, so it is not recorded. - Browser noise is filtered before it leaves your browser. Chrome’s “ResizeObserver loop completed with undelivered notifications” warning is a layout settling over two frames, not a fault, and a bare “Script error.” is the browser hiding the details of an exception thrown by a script it doesn’t trust (a browser extension, a third-party script loaded without CORS) — both are dropped on the spot, as is “Invalid call to runtime.sendMessage(). Tab not found.”, which only a browser extension can raise. Two more are dropped for the same reason: “Object Not Found Matching Id: …, MethodName: …, ParamCount: …”, raised by Microsoft Outlook’s link scanner when it opens a link someone was e-mailed, and “window.ethereum.selectedAddress = undefined”, which an in-app browser or crypto wallet injects into the page. A page left open across a CartonCrew release reloads itself once to pick up the new version; if it still cannot load part of the old one after that reload, that is the same stale page, not a fault, and it is not reported. The list is exact and very short so that real errors are never mistaken for noise.
- A web address that matches no gallery at all is not raised as a fault. Such a visit is noted, but with no organization behind it there is nothing of yours that failed, so no issue is opened for it.
- No personal data leaves your tenant. Reports are scrubbed before they’re stored: emails, phone numbers, and identifiers are masked, and form contents are reduced to field names — never values. Before a report reaches the CartonCrew team’s tracker, your organization’s name, its short name in your web address, and your gallery’s web address are replaced with placeholders, so a report never says which gallery it came from.
- Fixes are never automatic. Every proposed fix is reviewed by a person and goes through the normal release process. Because CartonCrew is one product serving many organizations, fixes reach everyone.
What you’ll see
If something breaks, you get a message that names what went wrong and, where we can, what to do about it — rather than a dead end. There is no incident list in the product: the reports go to the CartonCrew team, and the fix arrives in a release. Settings → About tells you which build you are on, and What’s new there lists the highlights of what has shipped.
Common issues
- “An unexpected error occurred” — that message means the failure was not one we had anticipated. It is always captured. If you can tell us what you were doing when it appeared, it speeds the fix up considerably.
- Worried about sensitive data — the scrubbing happens before anything is stored. The sub-processors page covers who processes what.
Last updated: 2026-09-13 · Applies to: CartonCrew v1.554+