1.What this document is — and what it is not
This is a Service Level Description. It tells you what we aim for, how the platform is actually built, and where its limits are. It is deliberately not a Service Level Agreement.
A contractual SLA with credits will follow once redundancy and independent external monitoring are in place — see section 9. Until then, please size your reliance on zutpralik accordingly: it is excellent at telling you your site went down, and it is not yet a system to bet a critical operation on without a second signal.
2.Availability target
| Item | Target |
|---|---|
| Monthly availability of the platform (dashboard, API and the monitoring worker) | 99.5% per calendar month — a target, not a guarantee |
| Equivalent unavailability allowance | Approximately 3 hours 39 minutes per 30-day month |
| Check execution | Checks are executed at the interval set by the plan — every 2 minutes (Basic), 60 seconds (Pro), 30 seconds (Business). Individual runs may be delayed under load or during maintenance. |
| Alert dispatch | Alerts are dispatched as soon as an incident is confirmed. Delivery time depends on the channel you configured — e-mail, Telegram, Slack, Discord, PagerDuty or your own webhook endpoint — and is outside our control once handed over. |
“Unavailable” means the dashboard or API returns errors, or the monitoring worker stops executing checks, for reasons attributable to us and outside the exclusions in section 5.
3.How the platform is actually built
You are entitled to know what stands behind the target, so here it is without decoration:
- One application server in Amsterdam, the Netherlands (EU), hosted by Xorek.Cloud. It runs the API, the web interface, the monitoring worker and the PostgreSQL database.
- No redundancy. There is no second server, no failover node and no second region. If that machine is down, zutpralik is down.
- Cloudflare sits in front as CDN and reverse proxy, and terminates TLS. The leg between Cloudflare and our origin server is not yet encrypted; we do not claim end-to-end encryption.
- Backups: daily database dumps, retained as 14 daily and 8 weekly copies, with restores verified rather than assumed. They are compressed but not encrypted, and they live on the same server. There is no off-site copy today, so they protect against corruption and accidental deletion — not against loss of the machine.
- No independent external heartbeat yet. We watch the platform from the inside. An outage that takes the whole server down also takes down the thing that would have noticed, which is precisely why we do not claim a measured uptime figure.
4.How availability is measured
Availability is measured per calendar month, in UTC, across the dashboard, the API and the monitoring worker, using our own operational records and the hosting provider’s reports. Excluded periods (section 5) are removed from both the numerator and the denominator.
Because there is no independent external observer yet, treat the figure as our best-effort account rather than an audited measurement. If you believe the platform was unavailable and our records disagree, write to [[CONTACT_EMAIL]] with your own evidence and we will investigate in good faith.
5.What is excluded from the target
The following do not count as unavailability:
- Planned maintenance announced as described in section 6, and emergency maintenance needed to address a security issue or imminent failure.
- Customer-side causes — misconfigured checks, incorrect notification channels, a webhook endpoint that is down or rejecting requests, a target site that blocks or rate-limits our probes, expired credentials, or account suspension for non-payment or breach of the Terms of Service.
- Third parties beyond our control — outages at Cloudflare or at the hosting provider, failures in your e-mail provider or in Telegram, DNS problems outside our zone, and general internet or transit degradation.
- Force majeure — natural disaster, war, terrorism, civil unrest, labour action, government act, power or network failure at the data centre, and large-scale denial-of-service attacks.
- Beta and preview features, and anything explicitly labelled experimental in the application.
- Suspension or degradation resulting from use that breaches the acceptable-use or authorisation rules in the Terms of Service.
6.Planned maintenance
- When. Planned maintenance is scheduled in a low-traffic window, normally between 01:00 and 05:00 CET.
- Notice. At least 48 hours’ notice by e-mail to account administrators, and a notice inside the application, stating the window and the expected impact. Most releases are deployed without downtime and are not announced.
- Emergency maintenance. Security fixes and work needed to prevent imminent failure may be carried out at any time with as much notice as circumstances allow — sometimes after the fact. We will always explain what happened.
- Your own maintenance. Independently of ours, you can schedule maintenance windows for a site or a whole client in the application, so that planned work on your side does not raise incidents or fire alerts.
7.Support response targets
Support is provided by e-mail at [[CONTACT_EMAIL]] during business hours — Monday to Friday, 09:00 to 18:00 CET, excluding public holidays. The times below are targets for a first substantive response, not for resolution, and no credits attach to them.
| Plan | Critical — platform unusable | Normal question |
|---|---|---|
| Basic | 1 business day | 2 business days |
| Pro | 8 business hours | 1 business day |
| Business (priority support) | 4 business hours | 1 business day |
A platform-wide outage is worked on as fast as we are able, regardless of plan, and does not wait for a support ticket.
8.If we have an outage
During an incident affecting the platform itself, we will:
- work to restore service as the first priority;
- inform account administrators by e-mail once we understand the scope, and again when it is resolved;
- for a significant outage, follow up with a plain-language explanation of what happened, what we did and what we are changing.
Note the obvious asymmetry: while zutpralik is down it is not checking your sites, and no alerts are generated for that period. Gaps in your history will reflect our outage, not your uptime.
9.When this becomes a real SLA
A contractual SLA — a committed availability figure, measured independently, with service credits when we miss it — requires infrastructure we do not have yet. Specifically:
- redundancy, so that a single server failure is not a total outage;
- off-site, encrypted backups, so that recovery does not depend on that machine;
- encryption between Cloudflare and the origin server;
- independent external monitoring, so that availability is measured by something other than the system being measured.
When those are in place we will publish a contractual SLA with credits and notify customers before it takes effect. We are not going to publish one before then. If your procurement process requires a signed SLA today, talk to us at [[CONTACT_EMAIL]] — we would rather have that conversation honestly than sign something we cannot honour.
This document forms part of the Terms of Service and is governed by the law of [[GOVERNING_LAW_COUNTRY]]. It does not create any contractual availability commitment or right to compensation.