Service commitments
What to expect, and what we do not promise
This page is not a service level agreement. There are no availability guarantees and no service credits, and we would rather say so here than bury it in a clause. What follows is what we work to, and how you can check it independently.
Why there is no contractual SLA
A service level agreement with credits is a financial obligation, and honouring it requires an on-call rotation, a company structure and insurance behind it. Beskos is operated by a small team, and none of those three are in place today.
Publishing a guarantee we could not honour would be the easiest paragraph on this site to write and the hardest to stand behind. The commitments below are objectives, tracked publicly, and we prefer to be measured against them than against a promise.
This changes when the structure supports it. At that point an SLA becomes a selling point rather than an exposure, and it will be published here.
What we work to
99.5%
Monthly availability
An objective for the application, the API and mail delivery, measured externally rather than by our own servers. It is not a contractual guarantee.
< 4 h
First response, service unavailable
For an incident that stops people working, during business hours in Central European Time.
< 1 business day
First response, everything else
Questions, configuration and requests that are not stopping anyone from working.
14 days
Notice of a new sub-processor
This one is a commitment, not an objective: it is written into the data processing agreement, with a right to object.
Checking it yourself
Every component is probed continuously from outside our infrastructure and published, with ninety days of history and a timeline for each incident. If our numbers and your experience ever disagree, the status page is the record, not our memory.
Open the status pageMaintenance and incidents
Planned maintenance
Announced in advance on the status page and scheduled outside European business hours. Most updates require no interruption at all.
During an incident
The status page is updated while it is ongoing, not afterwards: what is affected, what is known and what is being done.
Afterwards
Incidents that interrupt the service are documented with a timeline — detected, cause, resolved — and stay published.
Data, before availability
Backups are taken regularly to storage under European jurisdiction, each verified as readable, and restores are tested. An interruption is an inconvenience; losing data is not recoverable, and the two are not treated alike.
Questions before committing an organisation?
For a procurement process or a security questionnaire, write to us and you will get the answers in writing, including the ones that are inconvenient.