Service Level Agreement

Last modified: 21 April 2026

This Service Level Agreement ("SLA") sets out the availability and support commitments PRIVATEBYTE makes for its services, and the remedies available to you if we fall short. It forms part of our Terms of Service. Where this SLA and the Terms of Service conflict, the SLA prevails for availability, support response, and downtime remedy matters.

Our principle is simple: if we promise availability and miss, the service that failed is credited back on a clear formula, automatically. No paperwork, no hunting.

1. Scope

This SLA covers:

• VPS plans — Flare, Orbit, Comet, Pulsar, Quasar, Nebula
• OpenClaw — AI agent hosting instances
• Cross-Node VM Backup — availability of the backup mechanism itself, not recoverability of any individual snapshot
• Our client portal — login, VM management, billing actions
• Telegram bot — availability of the bot endpoint for account-linked users

The following have different availability characteristics and are addressed in their own subsections:

• Proxy services — Section 7
• DDoS protection — a passthrough service, no separate availability guarantee beyond the underlying VPS / network

2. Uptime guarantee

We target and commit to the following monthly uptime for the services listed above:

Uptime is measured per calendar month, separately for each service instance you hold. A single outage that affects multiple services counts separately against each one.

99.95% monthly is equivalent to approximately 21 minutes 54 seconds of permitted downtime per month.

3. What counts as downtime

For the purposes of this SLA, "downtime" means any period in which:

• VPS / OpenClaw: the service is unreachable over its assigned public IPv4 address for ICMP, TCP SYN, or the service's primary listening port, where the cause is within our reasonable control
• Portal: the portal at my.privatebyte.com returns HTTP 5xx, fails to load, or fails authenticated actions for a verified issue attributable to us
• Telegram bot: the bot fails to respond to /status or equivalent health-check command within 60 seconds

Downtime begins when our monitoring (or a customer report, whichever is earlier, provided the report is corroborated) confirms the outage. Downtime ends when service is restored.

4. Exclusions

The following are not counted as downtime and do not trigger credits:

• Scheduled maintenance announced at least 72 hours in advance (see Section 9)
• Emergency maintenance required to address security incidents, compromised components, or imminent service-affecting risks (see Section 10)
• Customer-caused outages — for example, configuration errors, exhausted disk, runaway processes, self-inflicted firewall rules, expired DNS, suspension for non-payment or AUP breach
• Force majeure — natural disaster, war, terrorism, civil unrest, pandemic, government action, sustained outage at upstream internet carriers, cable cuts, or prolonged facility infrastructure failure beyond our reasonable control
• Third-party dependencies outside our control — for example, upstream network providers, external DNS, payment processors, or the Telegram platform itself
• DDoS attacks mitigated within SLA response targets (defined in Section 5), even if individual traffic is dropped during mitigation
• Customer-requested actions — suspension, reinstallation, migration you initiated
• Time before we were reasonably able to act — for example, downtime occurring before your VM reached the compute node, or before our monitoring would reasonably be expected to detect the issue

5. Downtime credits

When monthly uptime falls below the guarantee for a specific service instance, we issue a service credit against that instance's monthly fee.

5.1 VPS and OpenClaw credit table

Maximum credit per service instance per month is 100% of that instance's monthly fee.

5.2 Portal credit

If the client portal uptime falls below 99.9% in a month, we credit 5% of each active service's monthly fee to affected customers, capped at 25% per customer per month.

5.3 Telegram bot credit

If the Telegram bot uptime falls below 99.5% in a month, no direct credit applies — the bot is a convenience interface, and core service management remains available through the portal and our email channels. We will publish a root-cause summary.

5.4 How credits are applied

• Credits apply to your account balance, automatically, once the incident is formally closed and the monthly calculation is finalised.
• Credits are not paid back to your original payment method. They offset future invoices. For the avoidance of doubt, this is distinct from refunds, which are governed by the Refund Policy.
• Credits do not expire while your account is active. On account closure you may request an equivalent refund of unused credits under the Refund Policy; unclaimed credits are forfeited at closure.
• Credit formula calculations are based on our incident records. We make them available to you on request — email [email protected] with the incident reference.

5.5 Aggregation and cap

For customers holding multiple service instances, credits are calculated per instance and aggregated to your account balance. There is no aggregate cap across instances. If five VPS instances each had a 100% credit month, you receive 100% × 5 in credits.

6. Support response targets

Our support targets, measured from the time we receive your request through the portal, by email to [email protected], or via the Telegram bot:

• Business hours for P3 are 09:00 to 18:00 UK local time, Monday to Friday, excluding English and Welsh public holidays.
• P1 and P2 are 24×7.
• "First response" means a human acknowledgement with a substantive update or a request for specific information — not an auto-reply.
• If you classify a request as P1 or P2 inappropriately (for example, asking a billing question as P1), we may reclassify it. We will tell you if we do.

7. Proxy service availability

Proxy services have a different availability model from VPS because traffic is relayed through upstream networks that we partner with but do not operate.

• We commit to 99.9% monthly availability of our proxy gateway (the endpoint your traffic connects to).
• We do not guarantee success of individual proxy requests, exit-IP geolocation accuracy, or upstream-network continuity beyond our reasonable control.
• If our gateway falls below 99.9% in a month, we apply a proxy balance credit equal to 10% of your consumption in that month, up to a maximum of 50% of consumption.
• Credits apply to your proxy balance automatically.

If you depend on specific upstream characteristics (e.g. guaranteed country-level geolocation), please raise it with us — we may be able to offer a higher-tier proxy plan with stronger commitments.

8. Incident communication

For any incident that crosses the threshold into an SLA-eligible event:

• Status page: we maintain an incident log at status.privatebyte.com (or a replacement equivalent). Incidents are posted as they are confirmed.
• Email: customers on affected services receive email notifications for incidents expected to exceed 15 minutes.
• Telegram: customers who have linked the Telegram bot receive instant notifications (subject to Telegram bot availability).
• Resolution: when an incident closes, we post a brief closing note and a root-cause summary where the cause is known. For significant incidents (SLA-triggering or customer-impacting), a post-mortem is published within 14 days.

9. Scheduled maintenance

• We announce planned maintenance at least 72 hours in advance by email, on the status page, and through the Telegram bot.
• Planned maintenance windows fall between 02:00 and 06:00 UK local time where the work is network-wide.
• Per-node or per-host maintenance is scheduled to minimise disruption to hosted customers and communicated individually.
• Time inside a properly-announced maintenance window does not count against uptime.

10. Emergency maintenance

Some incidents require immediate action — security advisories requiring same-day patching, active attack traffic requiring infrastructure reconfiguration, hardware failure pre-empting larger outage.

• Emergency maintenance may be carried out without the 72-hour notice.
• We notify customers as soon as reasonably practicable, including the reason and expected duration.
• Emergency maintenance does not count as downtime provided it is objectively required to prevent a larger incident. We publish a summary afterwards for customer review.

11. Customer responsibilities

To benefit from this SLA, you must:

• Keep your account in good standing (no unpaid overdue invoices)
• Provide a reachable contact email on your account
• Report suspected downtime promptly through the portal, email, or Telegram
• Not cause or materially contribute to the outage yourself
• Cooperate with our diagnostics — provide configuration, logs, screenshots if asked, within reasonable response windows

Credits may be reduced or withheld where we establish the outage was materially caused or prolonged by your own action.

12. Changes to this SLA

We may update this SLA from time to time. Material changes are notified to active customers by email at least 14 days before taking effect. Non-material changes (typos, clarifications, re-ordering) may be made without notice. The "last modified" date at the top of this page always reflects the current version. Previous versions are available on request.

Where we materially weaken an availability commitment and you do not accept the change, you may cancel the affected services before the change takes effect and receive a pro-rata refund of any pre-paid fees for the period after cancellation.

13. Contact

• Incident reports and P1/P2 escalation: [email protected]
• SLA credit queries: [email protected]
• Legal escalation: [email protected]
• Status page: status.privatebyte.com
• Post: PRIVATEBYTE, 128 City Road, London, EC1V 2NX, United Kingdom