Report Errors to Developer

Report errors to developer lets your Mumara Campaigns installation tell the Mumara team about unexpected errors automatically, so they can be investigated and fixed — often before anyone opens a support ticket. It is designed to be safe to leave on: reports are stripped of personal data, they are sent in the background so they never slow the application down, and you can turn the feature off at any time.

Where to find it

Where	What you see
Installation wizard → Administrator Account step	A pre-selected checkbox "Help improve Mumara by automatically reporting errors to the developers". Untick it to keep everything local.
Settings → Application Settings → Logs	The Report errors to developer switch, and next to it the Send diagnostic report now button.

Existing installations start off

Installations updated from an earlier version are not opted in. The feature stays off until an administrator switches it on under Application Settings → Logs and saves the tab.

What a report contains

Included	Purpose
The error message, type, and where in the application it happened (with the sequence of recent internal steps that led to it)	Lets the developers reproduce the problem
Application version and installation type (self-hosted, cloud, demo)	Tells them which release the problem is in
PHP version, database version, operating system, and IonCube version	Rules environment differences in or out
Installed addons and their versions	Identifies addon-related problems
Cron health — how long ago each scheduled job last ran	Explains "nothing is being sent" situations
A small, fixed set of non-sensitive settings (batch size, queue driver, log level, timezone, …)	Explains configuration-dependent behaviour
The last few lines of the application log, with personal data masked	Shows what the application was doing just before the error
Your license's client and service identifiers, the domain the application runs on, and the first characters of the license key	Lets the developers see which installation the report belongs to and reach out if needed

What a report never contains

• Your contacts — no email addresses, names, or custom-field data
• Email content — no templates, subjects, or bodies
• Passwords, API keys, tokens, or SMTP credentials
• Submitted form data, cookies, or browser sessions
• The user who was logged in when the error happened

In addition, every part of a report is scrubbed before it leaves your server: email addresses become [email], IP addresses become [ip], and anything that looks like a password, token, or key is replaced with [redacted].

What is not reported

Only problems in the application itself are reported. Failures of the environment around it are the server administrator's to fix, and are never sent:

• The database, cache, or mail server being down, refusing connections, or dropping the connection mid-query
• A full disk, a read-only file system, or file permission errors
• Wrong database credentials or an unknown database
• Outbound network failures — an unreachable Mumara service or a DNS failure
• The database server running out of connections or memory, or a query killed by the administrator

An hour-long database outage therefore produces no reports at all, rather than hundreds of identical ones.

Slow queries

Database queries that take longer than 5 seconds are reported as well, because a missing index or a badly shaped query often only shows on a large installation. Such a report carries the statement with every value replaced by a placeholder, how long it took, and the part of the application that ran it — never the values themselves. Schema changes and maintenance statements, which are expected to be slow, are skipped. Server administrators can change the threshold or turn slow-query reports off — see For server administrators.

How reports are sent

Reporting never happens during a page load or a sending run. When an error is caught, the report is written to a small local queue on your server and sent to the Mumara error tracker in the background by the scheduled tasks that already run every few minutes.

• Rate limits — the same error (or the same slow statement) is reported at most 5 times per hour, and an installation sends at most 200 error reports and 50 slow-query reports per day, so a runaway problem cannot flood anything.
• Unreachable tracker — if the tracker cannot be reached, reports wait in the local queue and are retried with increasing pauses; anything still unsent after 3 days is discarded. The queue is capped in size, so it can never fill your disk.
• Nothing when off — with the switch off, no error-reporting component is even loaded, so there is no overhead at all.

Send a diagnostic report on demand

Some problems do not produce an error — campaigns that stay queued, imports that seem slow, a cron job that appears stuck. For those, use Send diagnostic report now on the Logs tab:

1. Make sure Report errors to developer is switched on and the tab has been saved.
2. Click Send diagnostic report now.
3. Copy the Report ID that appears next to the button and quote it to support.

A diagnostic report carries everything an automatic report does, plus a fuller picture of the server — PHP extensions and limits, disk space, and the most recent entries from the application's own error list. It is sent immediately; if the tracker cannot be reached at that moment, the report is queued and sent within a few minutes, and the ID stays valid.

tip

Send a diagnostic report before opening a ticket about a "nothing happens" problem. It usually saves a round of back-and-forth about versions, cron settings, and log excerpts.

Turning it off

Switch Report errors to developer off under Settings → Application Settings → Logs and save the tab. Reporting stops immediately; anything still in the local queue is discarded on the next scheduled run.

For server administrators

Three optional values in the installation's .env file tune the feature for that server — useful when the same server image is deployed many times:

Variable	Effect
MUMARA_ERROR_REPORTING_ENABLED	true forces reporting on, false forces it off, regardless of the switch in Application Settings. Leave unset to follow the switch.
MUMARA_ERROR_REPORTING_DSN	Where reports are sent. Setting it to an empty value disables the feature completely; it is normally left unset.
MUMARA_ERROR_REPORTING_SLOW_QUERY_MS	Slow-query threshold in milliseconds (default 5000). Set it to 0 to turn slow-query reports off.

Run Tools → Config Cache (or php artisan config:cache) after changing .env values.

Frequently Asked Questions

Does it slow the application down? No. Reports are written locally and sent later in the background; nothing waits for the network.

Can the Mumara team see my subscribers or my campaigns? No. Contacts, email content, credentials, and form data are never part of a report, and email addresses or IP addresses that appear in an error message are masked before the report is created.

My server has no outbound internet access. Is that a problem? No. Reports simply wait in the local queue and are discarded after 3 days. The application is not affected either way. If that is your situation, you may prefer to leave the feature off.

My database server was down for an hour. Did that send hundreds of reports? No. Failures of the server around the application — the database being unreachable, a full disk, wrong credentials — are recognised and never reported at all. Only problems in the application itself are sent.

Where do the reports go? To an error-tracking service operated by Mumara. Reports are used only to diagnose and fix problems in Mumara Campaigns.

---

Related: Application Settings → Logs Tab · Debug Logs