Service levels and support
This page describes how Werkmail is monitored, how we communicate incidents and how you reach us. Nothing here is a contractual guarantee and there are no service credits unless your contract says otherwise. Enterprise customers can agree service levels in writing.
Monitoring and availability
The platform is monitored continuously from inside the service. For each component we record one check per minute and publish the result on the status page, which shows the measured availability of the last 90 days per component and the incident history.
We publish what we measure rather than a promised availability figure. We do not state an availability percentage as a contractual target.
The status page shows four components: API and dashboard, database, background jobs and mail sending. Mail sending is marked as failing when the connection to the outbound provider is refused and the circuit breaker opens.
What we do not count against us
- Planned maintenance announced on the status page ahead of time
- Problems caused by your own DNS, credentials, content or sending behaviour
- Delivery decisions of the receiving mail server, such as greylisting, spam filtering or a full mailbox
- Force majeure and failures of networks outside our control
Incidents
When customers are affected we open an incident on the status page, post an update when we have something to say and mark it resolved when it is fixed. Updates are written for customers and contain no personal data. We do not promise a fixed time to the first update.
The impact levels mean:
- Critical: sending or the API is unavailable for most customers
- Major: an important function is degraded or unavailable for some customers
- Minor: limited effect, a workaround exists
Support
| Item | Detail |
|---|---|
| Channel | Email to the support address shown on the website, in the imprint and in Settings |
| Staffed | During Central European business hours on working days, excluding Austrian public holidays |
| Response | We read every message and answer as quickly as we can. We do not commit to a fixed response time. |
| Abuse reports | Via the abuse form; handled with priority |
| Security issues | Via the contact in /.well-known/security.txt; please do not post details publicly |
When you write, include the workspace name, the affected domain, the time of the problem in UTC and, for a message, its id. That lets us answer without a second round of questions.
What you can do
- Subscribe to the status page by checking it from your monitoring. The JSON behind it is public at
GET /api/public/status(see the API reference). - Use
Idempotency-Keyon sends so a retry after an outage never duplicates a message. - Keep your own copy of anything you must be able to prove; delivery events and message bodies follow the retention periods in Compliance.