Crash Reporting

When the server hits an error, it records the details and emails them, so a defect is captured whether or not anyone thinks to report it. Errors that are a browser going away rather than a fault are recorded without being emailed — see Browsers going away below.

What a user sees

A page that fails to load shows Something went wrong with a short reference code, rather than a blank error. The reference is the id of the report that was just filed — quoting it in a support conversation finds the exact error.

Nothing the user typed is lost unless the page said otherwise.

What is sent

Reports go to support@evomedia.net using the Global Admin SMTP configuration (see Email / SMTP). Each one carries:

• the error type and its message, with email addresses, record IDs and long numbers redacted
• the application code locations involved — file, line and function
• the page path, without its query string
• the workspace slug, the build version, and the time
• how many times the same error has occurred since the last report

What is deliberately not sent

• Frame local variables. These are where record contents end up.
• Query strings, form values and request bodies.
• Anything a user typed.

Tracebacks routinely contain customer data, and a defect report is not a reason to move it off the server. The payload is a fixed allowlist rather than a dump, so adding to it is a deliberate change.

Grouping and volume

Errors are grouped by a signature — the error type plus the first application code location — so the same bug hit by two hundred people is one report rather than two hundred emails.

At most three reports per signature are sent per hour. Further occurrences are counted, not discarded, and the next report states the total. A different error is never blocked by a noisy one; the limit is per signature.

Browsers going away

Some errors are not faults. A person closing a tab, a laptop going to sleep, a connection dropping, or a deploy restarting the server under an open page all raise an error somewhere in the web machinery, and none of them mean anything is broken.

These are recorded but not emailed, and the report says which kind it was. Three are recognised today, all of them measured on a real installation:

What	Looks like
socket-disconnected	the page's live connection asked for an update after the browser had gone
asset-path-too-long	a browser asked for a file whose name was hundreds of characters of stylesheet
javascript-timeout	the server asked the page to run something and nobody was there

Each rule matches the error and where it happened, never the error type alone. That distinction is the point: a workspace that had 56 reports had 47 of these and 9 real ones, and the real ones were a single genuine defect that was hard to spot among the noise.

Nothing is deleted. The rows stay in the database with their reason, so "is this happening more than it used to?" is still a question you can answer — and if a kind of noise suddenly multiplies, that is worth knowing even though no single one of them is.

Configuration

Two optional environment variables on the server:

Variable	Default	Effect
CRASH_REPORT_ENABLED	on, except when APP_ENV=development	1 forces reporting on, 0 forces it off
CRASH_REPORT_TO	support@evomedia.net	Where reports are sent

Development and branch review servers do not send reports by default — an address that receives every experiment stops being read. Set CRASH_REPORT_ENABLED=1 there to verify delivery works.

If reports stop arriving

Every report is written to the database before the email is attempted, and the outcome of that attempt is stored with it. So an empty inbox is either no crashes or a mail problem, and the two are distinguishable — the rows are still there either way. This is deliberate: an earlier defect was a hung outbound mail call, and a reporter that only emailed would have failed in exactly the same way it was trying to report.

Check the Global Admin SMTP settings first.