Service Level Commitment
What 99.98% uptime means in minutes, how it is measured, what is excluded from it, and how to claim when we miss it.
Last updated:
The commitment
Pixoof Teknoloji Anonim Şirketi commits to 99.98% monthly availability for each ServerQ virtual and dedicated server, measured per service rather than across the fleet. It is a commitment about the future, not a report of the past: this site does not publish an achieved uptime figure, because it has no public monitoring to derive one from, and a number with nothing behind it is worth less than an honest silence.
| Period | Downtime the commitment allows |
|---|---|
| One 30-day month | 8 minutes 38 seconds |
| One quarter | 26 minutes 17 seconds |
| One year | 1 hour 45 minutes |
What counts as downtime
Your service is down when it is not reachable from outside our network for reasons within our control: the host is off, the hypervisor has failed, the network segment your server sits on is unreachable, or the upstream link from the facility is down. Downtime is measured from the first failed check to the moment service is restored, in whole minutes.
What is excluded
- Planned maintenance announced in advance. We give notice in the portal and by e-mail, and we schedule it outside Türkiye business hours wherever the work allows.
- Anything caused by your own configuration, software or content: a full disk, a misconfigured firewall, a kernel that will not boot after you changed it, an application that has stopped.
- Suspension under the Acceptable Use Policy or for an unpaid invoice.
- Failures of networks between you and us — your ISP, a transit provider, a route that flaps somewhere neither party controls. Your server being unreachable from one particular network while reachable from others is not downtime, though we will still help you trace it.
- Force majeure as defined in the Distance Sales Agreement.
The network the commitment runs on
Servers connect on a 2x25 Gbps LACP bonded port, and the datacenter uplink is 2x100 Gbit. The commitment above is about availability, not about throughput: a port speed is the ceiling of a link, and what a given transfer reaches depends on the far end and the route as much as on us. We do not commit to a throughput figure because we could not honestly measure one on your behalf.
Claiming
Open a ticket within thirty days of the incident, with the service, the dates and times with their timezone, and whatever evidence you have — monitoring output, traceroutes, your own logs. We check it against our records and reply with what we find, including when what we find does not support the claim.
Where the commitment was missed, the remedy is a credit against future invoices rather than a cash refund, assessed against the length of the outage and the value of the affected service. A fixed tier table is not published here yet, and we would rather say that than publish percentages we have not committed to internally — ask before you buy if the exact figure matters to your decision, and you will get it in writing.
How this will be measured publicly
There is no public status page yet, and until there is, the honest position is that availability is measured by us and checked by you against your own monitoring. That is a weaker arrangement than a status page with independent probes, and we are not going to describe it as anything else. When there is one, its history will be published from the day it starts, not from a date chosen to look good.