Troubleshooting
Something is broken — how to report it
Tell us through the contact form
The contact form creates a support ticket and its first message in one step — a ticket cannot exist without the message explaining it, so nothing lands in a queue with no description. If you are signed in when you send it, the ticket is linked to your account, taken from your session rather than from anything you type.
Replies usually arrive within two working days. There is no phone line. If you would rather
write directly, [email protected] reaches the same place, [email protected] is for
everything else and [email protected] for legal notices.
The form accepts five messages an hour from one address. The hidden website field is a trap for bots; leave it empty.
What makes a report useful
Four things, and nothing else is needed:
- What you did, in the order you did it.
- What you expected.
- What happened instead, quoting any message word for word.
- Which app and browser, and roughly when — the time narrows a search that a description cannot.
Check the status page
The status page lists each service and its current state. Read it with one caveat: the states are set by hand, not by automated probes. It is a statement of what we know, not a live reading, so a green tick means nobody has reported a fault, not that a machine checked a minute ago. The Nova relay is listed as not deployed, which is a fact about the service rather than an outage.
If something is broken while the status page says otherwise, that is itself worth reporting.
What an error report contains
There is an endpoint that accepts error reports from the apps, and everything it receives is redacted before it is stored, not before it is displayed. A redacted log can be shared with anyone; a raw one can never be un-leaked. It removes:
| Fields named for secrets | authorization, token, password, cookie, api_key, secret, card numbers and the rest — the value is dropped whole, whatever it looks like |
| Session tokens | Any JWT, and any Bearer or Basic credential |
| Provider keys | The sk-, pk-, gh…_ and re_ shapes, wherever they appear in text |
| Sensitive query parameters | ?token=, ?code=, ?secret=, ?signature= and similar become <redacted> |
| Email addresses | Replaced with <email> |
| Card-shaped numbers, IPv4 and IPv6 addresses | Replaced with a label |
The structure is capped as well — four levels deep, forty keys, twenty array entries, and messages and stacks truncated — because an error report is not a place to accept an arbitrary object from a browser. Your IP address is never stored: what is kept is a salted hash of it, enough to tell one broken client from a thousand and useless for anything else. If you were signed in, the report carries your account id, not your address.
No app sends these automatically yet. The endpoint, the redaction and the grouping exist; the wiring inside the apps that would call it does not. So for now, a bug we do not hear about from you is a bug we do not know about.
Last updated . Something wrong or missing? Tell us — it is the fastest way to get it fixed.