Service Level Agreement

The service-level agreement is the document that sets out the operator’s quantitative commitments in respect of the availability of the OffshorePress hosting service and the operator’s responsiveness to subscriber-raised incident tickets. The agreement is published in plain editorial English in preference to the boilerplate register that the commercial-hosting industry has gravitated toward, on the view that a quantitative commitment a subscriber is asked to rely on should be expressed in terms the subscriber can read and verify. The substantive content of the agreement — the uptime targets, the credit ladder, the severity ladder, and the exclusions — is binding on the operator and forms an integral part of the contractual terms set out at /legal/tos.

The drafting posture of this agreement is conservative. The operator’s view is that an honest service-level agreement is one whose targets the operator can meet under the operator’s actual operating conditions, including the carrier-circuit constraints, the data-centre power constraints, and the planned-maintenance windows that the operator’s facility providers impose on the operator. An aspirational target the operator misses every quarter is worse than a sober target the operator meets every quarter; the targets below are sober.

1. Uptime targets

1.1 Standard tier

The operator targets 99.9% monthly uptime for the standard tier. The standard tier comprises the entry-level VPS plans (VPS-1 through VPS-4), the entry-level dedicated machines (DS-LITE), and the standard email plans (Mail-1 through Mail-4) as identified on the relevant product pages.

The 99.9% target permits an outage budget of approximately 43 minutes 49 seconds per calendar month, computed against a 30-day month. The operator’s measurement methodology is set out in section 5 below.

1.2 Pro tier

The operator targets 99.99% monthly uptime for the Pro tier. The Pro tier comprises the higher-specification VPS plans (VPS-8 through VPS-16), the higher-specification dedicated machines (DS-PRO and DS-BEAST), and the unlimited-mailbox email plan (Mail-Unlimited) as identified on the relevant product pages.

The 99.99% target permits an outage budget of approximately 4 minutes 23 seconds per calendar month, computed against a 30-day month. The Pro tier is configured with redundant power feeds, redundant network paths, and a hot-spare allocation that the standard tier does not enjoy.

The placeholder caveat: the precise composition of the Pro tier and the precise targets the operator is willing to commit to are pending the operator’s pre-launch review of its actual measurement against the target over the operator’s first ninety days of customer-bearing operation. The targets above are the operator’s working targets; counsel review will confirm whether the targets are sustainable or whether the operator should adjust the Pro tier downward to a more conservative number before commercial launch.

2. Credit ladder

Where the operator misses an uptime target in a calendar month, the operator credits the subscriber’s account against the next invoice for the affected service in accordance with the ladder below. Credits are computed against the invoice value of the affected service for the calendar month in which the outage occurred.

2.1 Standard tier (99.9% target)

Monthly uptime achieved	Credit
99.0% to 99.89%	10% of the monthly invoice value
95.0% to 98.99%	25% of the monthly invoice value
90.0% to 94.99%	50% of the monthly invoice value
Below 90.0%	100% of the monthly invoice value

2.2 Pro tier (99.99% target)

Monthly uptime achieved	Credit
99.9% to 99.989%	10% of the monthly invoice value
99.5% to 99.899%	25% of the monthly invoice value
99.0% to 99.499%	50% of the monthly invoice value
Below 99.0%	100% of the monthly invoice value

A credit issued under the ladder above is the subscriber’s exclusive remedy for a missed uptime target. The credit is set off against the next invoice issued in respect of the affected service; the operator does not pay credits in cash, in cryptocurrency, or by reversal to the original payment method.

3. Severity ladder for support response

The operator’s customer-support team triages incoming tickets against the four-level severity ladder below. The severity classification is the operator’s call on intake; a subscriber who considers that the operator has misclassified the severity may request a review by replying to the ticket acknowledgement.

3.1 Severity 1: total outage

Severity 1 covers a total outage of the subscriber’s service — the subscriber’s VPS is unreachable on the subscriber’s primary IPv4 address, the subscriber’s dedicated machine is powered off or has lost network connectivity in full, the subscriber’s email service is rejecting connections at the SMTP edge. The operator targets a fifteen-minute response time on Severity 1 tickets and a four-hour resolution-or-mitigation time. Severity 1 tickets are paged to the operator’s on-call engineer regardless of business hours.

3.2 Severity 2: significant degradation

Severity 2 covers a significant degradation of the subscriber’s service that does not amount to a total outage — the subscriber’s VPS is reachable but is exhibiting elevated packet loss above 5% sustained, the subscriber’s dedicated machine is rebooting unexpectedly without operator-initiated cause, the subscriber’s email service is delivering mail with sustained latency above thirty minutes. The operator targets a one-hour response time on Severity 2 tickets and a twelve-hour resolution-or-mitigation time. Severity 2 tickets are paged to the on-call engineer outside business hours where the engineer is on shift.

3.3 Severity 3: routine fault

Severity 3 covers a routine fault that does not significantly degrade the service — a non-urgent configuration change request, a question about a billing-record entry, a request for a non-emergency reboot, a routine support enquiry about the operator’s infrastructure or policies. The operator targets a one-business-day response time on Severity 3 tickets and a five-business-day resolution-or-mitigation time.

3.4 Severity 4: feature request or general enquiry

Severity 4 covers a feature request, a general enquiry, or a non-fault interaction with the operator. The operator targets a five-business-day response time on Severity 4 tickets; the operator does not commit to a resolution time on Severity 4 tickets, on the basis that the appropriate disposition of a feature request or a general enquiry is rarely a discrete resolution event.

4. Exclusions

The credit ladder in section 2 does not apply to outages caused by the following circumstances. An outage caused by a circumstance enumerated below does not contribute to the operator’s monthly uptime measurement and does not give rise to a credit under the ladder.

4.1 Force majeure

An outage caused by a circumstance beyond the operator’s reasonable control, including (without limitation) acts of war, acts of civil authority, natural disasters, pandemic public-health emergencies, large-scale failure of public telecommunications infrastructure, and large-scale failure of the electricity grid serving the operator’s data-centre facility. The force-majeure exclusion is the operator’s interpretation of the same concept articulated in the contractual terms at /legal/tos section 12 and is consistent with that articulation.

4.2 Scheduled maintenance

An outage caused by maintenance scheduled by the operator or by the operator’s data-centre provider, where the operator has given the subscriber not less than seven days’ notice of the maintenance window. Scheduled-maintenance windows are limited to a target of one window per quarter per affected service, with a target window length of not more than four hours. The operator publishes scheduled-maintenance notices to the operator’s status page (which the operator commits to publishing as part of the F12 SEO-infra session) and to the contact email address on the affected subscriber’s account.

4.3 Customer-side misconfiguration

An outage caused by a misconfiguration of the subscriber’s workload that the operator has not made or recommended. The operator’s incident-response team will, on a best-efforts basis, assist the subscriber to identify and to remediate a customer-side misconfiguration; the time spent in such assistance is not counted toward the operator’s uptime measurement.

4.4 Customer-requested action

An outage caused by an action the operator has taken at the subscriber’s request — a power cycle, a reinstall, a firewall reconfiguration. The operator’s confirmation of the request before action is the operator’s only safeguard against this exclusion being mis-applied; subscribers are encouraged to read the operator’s confirmation message in full before authorising the action.

4.5 Suspension under the contractual terms

An outage caused by a suspension of the service under the contractual terms at /legal/tos section 8 or under the acceptable use policy at /legal/aup. A suspension that is later determined to have been imposed in error is credited under section 8.1.3 of the contractual terms; that credit is the subscriber’s exclusive remedy for an erroneous suspension and is not additive to the credits in section 2 above.

4.6 Distributed-denial-of-service traffic

An outage caused by distributed-denial-of-service traffic against the subscriber’s service, where the traffic exceeds the operator’s standard-tier mitigation capacity, is excluded from the standard-tier uptime measurement. The Pro tier’s uptime measurement excludes only DDoS traffic that exceeds the Pro-tier mitigation capacity (which is materially higher); a Pro-tier subscriber who is the target of a DDoS event whose volume falls within the Pro-tier mitigation capacity has the event count toward the operator’s uptime measurement and may be eligible for a credit under section 2.2.

5. Measurement methodology

The operator measures monthly uptime per service from two independent vantage points: the operator’s own monitoring infrastructure (which polls the subscriber’s service from a host inside the relevant data centre) and an external third-party monitoring service (which polls the subscriber’s service from a host outside the data centre). A service is considered “down” for the purposes of the credit ladder where both vantage points record a failure for at least three consecutive polls. The polling cadence is one-minute on the standard tier and thirty-second on the Pro tier.

The operator does not currently publish per-service measurement data on the status page; the F12 SEO-infra session is expected to ship the status-page surface, at which point the operator will publish historical uptime measurements per data centre and per service category. In the interim, a subscriber who wishes to verify the operator’s measurement against an outage should request the per-incident measurement record at the contact form at /contact within thirty days of the outage.

6. Credit-claim process

A subscriber who believes the subscriber is entitled to a credit under section 2 above must submit a written claim to the contact form at /contact within thirty days of the end of the calendar month in which the outage occurred. The claim must identify the affected service, the outage date and approximate duration, and the credit-ladder bracket the subscriber considers applicable.

The operator processes credit claims within ten business days of receipt. The operator’s response either (a) confirms the claim and applies the credit to the subscriber’s account against the next invoice, (b) confirms a partial claim and applies a partial credit, or (c) declines the claim with a written explanation that sets out the operator’s analysis. A subscriber who disagrees with a declined claim may escalate the matter to the contact form at /contact for review by the operator’s senior operations officer.

7. Modifications

The operator may modify this agreement at any time by publishing a revised version. The revised version takes effect on the effective-from date stated in its frontmatter; the operator will, where reasonably practicable, give notice of a material modification to existing subscribers by email at least thirty days before the effective-from date. Continued use of the service after the effective-from date constitutes acceptance of the revised agreement.

The operator’s modification posture on this agreement is asymmetric: the operator may improve the agreement (increase the uptime targets, increase the credit percentages, decrease the response times) at any time without notice, but a material adverse modification (decrease the uptime targets, decrease the credit percentages, increase the response times) is subject to the thirty-day notice requirement above.

8. Operator contact

Service-level enquiries, credit claims, and questions about the agreement itself are routed to the contact form at /contact. The mailbox is monitored by the operator’s customer-support team during business hours and by the operator’s on-call engineer outside business hours; the on-call rotation covers the entire week.