Module · Diagnostics
Wintertrace Diagnostic
An opt-in module that submits a structured error record to the maintainer when Wintertrace misbehaves — technical detail only, no business data, and only with an API key in place.
- Version
- 1.0.4
- Released
- 25 Jun 2026
- Languages
- German, English
When Wintertrace doesn’t behave as expected
Self-hosted software runs in environments the maintainer never sees. That makes a single category of support ticket — “it doesn’t work” — effectively unsolvable by email.
The Diagnostic module closes that gap. Instead of a back-and-forth that asks for screenshots, version numbers, server logs and PHP configurations one at a time, the affected installation submits a structured error record on its own — once, with everything the maintainer needs to reproduce the fault.
The module is opt-in. Without an API key it does nothing. With a key, it transmits only the technical detail of an error event — nothing about who triggered it, nothing about the surrounding business data, and nothing without a real fault to report.
What is sent — and what isn’t
Two independent filter layers — one inside the Wintertrace core,
one at the receiving endpoint on
api.noschmarrn.dev — strip anything
that isn’t strictly diagnostic. If one layer misses something, the
other catches it.
What is transmitted?
The error message, a stack trace with relative file paths, the PHP, Laravel and Wintertrace version, the list of active modules, the route name that triggered the fault, and the timestamp.
What is excluded?
Email addresses, IP addresses, passwords, API tokens, session identifiers, cookies, submitted form values and local variables. None of this leaves the installation. The exclusion is enforced both at the source and at the endpoint — the receiving server rejects payloads containing fields it doesn’t expect.
How long is the data kept?
Until the support case is closed — at most seven days. After that, every record received from the installation is deleted on the maintainer side. A single support case is also capped at 500 error events; the module stops submitting on its own once that ceiling is reached.
How is diagnostics stopped?
The module settings dialog has an End diagnostics button. It takes effect immediately: the local API key is cleared and no further events are transmitted, even if more faults occur.
How to activate diagnostics
Five steps. The API key is the switch — without one, the module sits dormant.
- 1
Install the module
Through the admin area or by uploading to
modules/— both routes are described below. - 2
Request an API key
Send a short email to support@noschmarrn.dev describing what you’re seeing. There’s no form to fill in.
- 3
Receive your personal key
Tied to your installation and your support case. Free of charge.
- 4
Paste it into the module settings
The key lives only in your installation. It is never transmitted as part of an error payload.
- 5
From here on, faults are reported automatically
Until you press End diagnostics or seven days have passed — whichever comes first.
File integrity
Every published module is signed against the same Ed25519 root key used for Wintertrace core updates. The values below come straight from the catalogue API.
- Size
- 34 KB
- SHA-256
- 3e107b6646ad…daf52226
- Released
- 25 Jun 2026
- Languages
- German, English
Install this module
The same two paths as any Wintertrace add-on.
From the admin area
Open the Modules menu inside a running Wintertrace installation. Pick Wintertrace Diagnostic from the catalogue and install with one click.
Manually via FTP
Download the archive, unpack it, and upload the folder to
modules/ inside your installation.
New here? The installation page walks through a fresh setup first.
Download
The module is served from the Wintertrace add-on registry at
jenni.noschmarrn.dev — the same source
the admin area pulls from.
External link — the download is served from the maintainer's registry at jenni.noschmarrn.dev and verified against the SHA-256 above.