Service Levels

1. How service commitments apply

This page explains the service-level framework used for ShivHost. It does not create a universal uptime guarantee, support response time, or service credit by itself.

A numerical commitment applies only when the accepted order identifies the covered service, target, measurement source, period, exclusions, and remedy. This protects both parties from treating a general website statement as a workload-specific operating promise.

If an order contains no numerical commitment, we will still use reasonable care and skill to operate the service, communicate material incidents through an appropriate channel, and restore affected service according to impact and available recovery options.

2. Availability measurement

When an uptime target is included, availability is normally measured for the covered service over the calendar or billing month stated in the order, using our monitoring and incident records. The order should define what endpoint or infrastructure layer is measured and when unavailability begins and ends.

Application errors, a slow third-party dependency, DNS outside our control, customer firewall rules, depleted customer resources, or an inaccessible admin function may not mean that the covered hosting service is unavailable. The specific measurement boundary in the order controls.

3. Maintenance and exclusions

The following periods are excluded from an availability calculation unless the order expressly includes them:

• Announced scheduled maintenance and urgent security maintenance.
• Customer-requested work, customer configuration, customer software, or actions by customer users.
• Suspension permitted by the Terms of Service or Acceptable Use Policy.
• Internet routing, domain, registry, third-party SaaS, or upstream services outside the covered boundary.
• Attacks, force-majeure events, widespread provider failures, or unlawful activity that could not reasonably be prevented.
• Beta, trial, preview, free, or unsupported components identified as such.

Where practical, planned disruptive work will be scheduled to reduce impact and communicated in advance. Urgent work may proceed without advance notice when necessary to protect customers or infrastructure.

4. Support and incident handling

Support availability, channels, and response targets are plan-specific. A response target measures acknowledgement or initial engagement, not guaranteed resolution. Resolution time depends on cause, access, vendor involvement, customer cooperation, restore size, and safe recovery options.

Customers must provide the affected service, time observed, error or symptom, recent changes, and a safe contact method. Do not include passwords, private keys, full payment credentials, or unrelated personal data in a ticket.

We prioritise incidents by customer impact, security risk, affected scope, and availability of a workaround. A security event or broad outage may take priority over a lower-impact individual request.

5. Claims and service credits

If an order includes service credits, the customer must submit a claim within the claim window stated in that order and provide enough information to identify the incident. We compare the claim with monitoring, maintenance, and support records.

Credits are calculated only as stated in the order, apply to future fees for the affected service, and are capped by the covered service fee for the relevant period. Credits are the sole remedy for failure to meet that specific target unless applicable law or the order states otherwise.

Credits do not apply to overdue accounts, excluded events, duplicate claims, or incidents not reported within the stated window. Refund requests outside a service-level remedy are governed by the Cancellation & Refund Policy.