Draft policy for operator review. This theme is connected to WHMCS: a configured installation can create customer accounts, orders, invoices and support records, and use enabled payment and service modules. Before adopting this policy, the operator must complete its verified identity, contacts, service terms and actual data practices. Installing the theme does not configure those business settings.
- Uptime guarantee
- Only if agreed in your order
- Measurement
- Defined service boundary
- Preview status
- No live monitoring
Service-specific commitments
This model policy explains how a live service-level schedule should work. It does not publish an uptime percentage, guaranteed response time or automatic credit for every Weeby product. The accepted order must identify the covered service, target, measurement period, monitoring method, exclusions and remedy.
Web Hosting, Cloud Hosting, Reseller Hosting, VPS, Dedicated and Game Servers can have different infrastructure boundaries. Professional Email and VPN may depend on a selected platform. Domains and SSL involve registry or certificate-authority processes; design, migration, backups and managed work require delivery or recovery commitments suited to their scope.
Define the measurement boundary
A schedule must say what is being measured: for example, a specified network interface, virtual machine, managed application endpoint or mailbox platform. Infrastructure reachability, application health and the ability of a customer’s own code to complete a transaction are different measurements.
- Identify the service ID, region or location, and the beginning and end of the covered period.
- Specify the monitoring points, test frequency and conditions that make an incident qualifying unavailability.
- Explain how overlapping incidents, partial degradation and disputed telemetry are handled.
- State who keeps the relevant records and how a customer can submit evidence for review.
Availability calculation
For an agreed monitoring period, eligible minutes are the covered minutes after exclusions expressly allowed by the accepted schedule. Qualifying unavailable minutes must fall within that same service boundary and period.
(eligible minutes − qualifying unavailable minutes) ÷ eligible minutes × 100
Do not subtract the same excluded period twice or count overlapping downtime more than once. The schedule should state any rounding rule and how a period with no eligible monitoring minutes is handled. A monthly average alone does not describe latency, packet loss, data integrity or application performance.
Maintenance and exclusions
Planned maintenance should follow the notice, timing and emergency process agreed for the service. The schedule must distinguish ordinary planned work from urgent work required to protect systems. A maintenance label should not be used to retrospectively remove an otherwise qualifying incident.
A live schedule may define exclusions for specific customer-controlled failures, unauthorised changes, external dependencies or other events, where lawful. Exclusions must be stated in advance, relevant to the service boundary and supported by evidence. This model does not automatically exclude every network attack or third-party incident.
Notify affected customers through the agreed channel when practicable and explain any action needed on their side. A service-status page should report verified information rather than displaying a generic “operational” label without monitoring.
Support and recovery targets
Response time measures an initial meaningful reply; resolution time measures restoration or completion. They are not interchangeable. The accepted support schedule must define coverage hours, time zone, severity levels, eligible channels and when the clock begins or pauses.
Backup recovery-point and recovery-time objectives, if purchased, must identify protected systems, retention, restoration dependencies and testing assumptions. A scheduled backup alone does not establish a guaranteed recovery objective.
Project services should instead define milestones, acceptance criteria, customer dependencies and change control. Do not apply an infrastructure uptime calculation to a design revision or migration deliverable.
Incident reports and credit requests
Report an incident using the published support route and include the service ID, impact, start and end times with a time zone, relevant errors and any safe diagnostic evidence. Do not expose credentials or unrelated customer data.
Any claim deadline, credit bands, eligible fee base, cap and method of issue must be stated in the accepted schedule. If no target and credit schedule has been agreed, this policy does not create one. A provider should explain its calculation and allow an appropriate review of disputed evidence.
Credits normally apply to the affected service as the accepted schedule specifies. They are not the same as a cash refund and do not remove remedies that cannot lawfully be excluded. See the Refund & cancellation policy.
This preview and live implementation
The calculator above performs arithmetic on the values entered; it is not a live monitor or incident feed. Client-area service records and statuses are supplied by WHMCS and configured modules. Those billing or provisioning states are not, by themselves, an uptime measurement or evidence that a contractual service target has been met.
Before adopting a service-level agreement, configure actual monitoring, support routing, maintenance notices, evidence retention and credit approval. Report service issues through the operator’s designated WHMCS support department or published urgent route. The general contact form is not a substitute for an agreed incident-reporting process.
Explore the services and review the terms relevant to your project.
