Service Level Agreement

1.1This SLA applies to hosting and infrastructure services for which SKPHost expressly states that this SLA applies.

1.2The purpose of this SLA is to define how service availability is assessed and to distinguish SKPHost-controlled service interruptions from events outside SKPHost’s reasonable control.

1.3This SLA does not create an unconditional guarantee that any service will operate continuously or without interruption.

1.4Features, infrastructure and technical characteristics may vary between products, servers and locations.

2.1SKPHost aims to maintain reliable availability of its hosting services and uses commercially reasonable efforts to keep eligible services operational.

2.2Service availability may depend upon third-party datacenters, network carriers, transit providers, hardware providers, power infrastructure and other upstream services.

2.3An availability target, where specifically stated for a service, is subject to the exclusions and measurement rules contained in this SLA.

2.4An availability target must not be interpreted as a promise that a service will never experience downtime, degradation, maintenance or interruption.

2.5SKPHost does not publish an unconditional uptime guarantee for infrastructure or events outside its reasonable control.

3.1An interruption may be treated as SKPHost-controlled downtime where an eligible service becomes materially unavailable primarily because of a failure within systems or configurations under SKPHost’s reasonable operational control.

3.2This may include failure of an SKPHost-controlled hosting configuration, a material provisioning error caused by SKPHost, or an SKPHost-controlled network or routing configuration error.

3.3It may also include failure of an SKPHost-managed service component where SKPHost is responsible for operating that component, or another infrastructure failure reasonably determined to be within SKPHost’s operational control.

3.4A temporary performance variation does not automatically constitute downtime unless the affected service is materially unavailable.

4.1SKPHost may obtain servers, rack infrastructure, power, connectivity, IP transit, network capacity or other infrastructure from independent third-party providers.

4.2An interruption caused solely by a third-party datacenter, upstream carrier, transit provider, power provider or other external infrastructure provider, where the underlying event is outside SKPHost’s reasonable control, will not automatically be classified as SKPHost-controlled downtime.

4.3Examples may include a datacenter-wide network outage, upstream carrier or routing failure, datacenter power or cooling incident, fibre or connectivity failure, upstream hardware failure, provider emergency maintenance, or failure affecting infrastructure controlled exclusively by an upstream provider.

4.4The use of a third-party provider does not by itself exclude every service interruption from this SLA. The cause of the incident and the portion of the infrastructure reasonably controlled by SKPHost will be considered.

4.5Where an upstream incident occurs, SKPHost will use commercially reasonable efforts to communicate with the relevant provider and facilitate restoration of the affected service.

4.6Restoration time may depend upon the responsible third-party provider, and SKPHost cannot guarantee a restoration time for infrastructure outside its reasonable control.

5.1SKPHost may perform scheduled maintenance where reasonably necessary to maintain security, stability, performance or reliability.

5.2Where practical, advance notice of maintenance expected to materially affect service availability may be provided through an appropriate communication channel.

5.3Scheduled maintenance will not normally be classified as qualifying SLA downtime.

5.4Maintenance windows may vary depending on the affected infrastructure and urgency of the work.

6.1Emergency maintenance may be required without advance notice where immediate action is reasonably necessary to protect infrastructure, Customers or service integrity.

6.2This may include urgent action relating to critical security vulnerabilities, hardware or network instability, serious software defects, active attacks, datacenter emergencies, or conditions presenting a material risk of data loss or wider service disruption.

6.3Reasonable emergency maintenance will not normally qualify as SLA downtime.

7.1SKPHost may use security or DDoS mitigation technologies where available for the applicable service.

7.2Security and DDoS protection reduces risk but cannot guarantee protection against every attack.

7.3An interruption caused by an attack that exceeds available mitigation capacity, targets a third-party network, causes upstream null-routing, or otherwise creates conditions outside SKPHost’s reasonable control will not normally qualify as SKPHost-controlled downtime.

7.4SKPHost may temporarily filter, restrict, reroute or isolate affected traffic where reasonably necessary to protect infrastructure or other Customers.

8.1The following will not normally qualify as infrastructure downtime where the SKPHost-provided platform itself remains operational: website code errors; WordPress, CMS, theme or plugin failures; Customer-installed software or applications; PHP or application configuration errors; or database queries and application workloads causing excessive resource consumption.

8.2Customer firewall, DNS or network configuration, incorrect nameserver or DNS records, expired or incorrectly configured third-party services, and Customer modifications to a VPS or Dedicated Server operating system will not normally qualify as SKPHost-controlled downtime.

8.3Malware, compromised credentials or security incidents originating from Customer Content or Customer-controlled software will not normally qualify as SKPHost-controlled downtime.

8.4Resource exhaustion resulting from Customer-controlled workloads will not normally qualify where the underlying SKPHost infrastructure remains available.

9.1For VPS and Dedicated Server services, infrastructure availability is distinct from availability of the Customer’s operating system, applications, control panel, websites or other Customer-managed software.

9.2A VPS or Dedicated Server may be considered infrastructure-available even where a Customer-managed application or operating system is not responding.

9.3Where a service is unmanaged, Customer-side administration, software configuration and operating-system issues are outside the infrastructure availability calculation.

9.4For managed services, SKPHost’s responsibility is limited to the management scope expressly included with the applicable service.

10.1DNS propagation, registry operations and third-party DNS systems may affect whether a website or service can be reached.

10.2An interruption caused exclusively by a domain registrar, registry, external DNS provider or Customer-controlled DNS configuration will not normally qualify as SKPHost-controlled downtime.

10.3Failure of an unrelated third-party API, CDN, payment provider, email provider, software vendor or external integration does not constitute SKPHost infrastructure downtime merely because it affects a Customer application.

11.1SKPHost will not treat an interruption as SKPHost-controlled downtime where it results from circumstances that could not reasonably be controlled or prevented by SKPHost.

11.2Depending on the circumstances, this may include natural disasters, fire or flooding, war or civil disturbance, governmental action, widespread internet disruption, major telecommunications failure, external power-grid failure, labour disruption affecting external providers, major cyberattack, failure of critical third-party infrastructure, or comparable events outside SKPHost’s reasonable control.

11.3This section does not exclude responsibility for matters that applicable law does not permit SKPHost to exclude.

12.1Service availability will be assessed using information reasonably available to SKPHost concerning the affected infrastructure, including internal monitoring systems, server and network logs, datacenter or upstream-provider incident reports, service monitoring records, Customer reports and relevant technical evidence.

12.2A Customer-side monitoring alert alone does not conclusively establish qualifying downtime.

12.3Where monitoring systems provide conflicting results, SKPHost may investigate the affected server, network path, service and incident records to determine the actual cause and duration.

12.4Downtime measurement, where applicable, begins when the eligible service is confirmed to be materially unavailable due to a qualifying cause and ends when material availability is restored.

13.1Customers should report suspected infrastructure outages through the SKPHost Support system as soon as reasonably possible.

13.2SKPHost may request information reasonably necessary to investigate the incident, including the affected service, time of occurrence, error information and relevant diagnostic details.

13.3An incident will be classified according to its reasonably determined technical cause rather than solely according to the symptoms observed by the Customer.

13.4Where the cause cannot reasonably be verified as SKPHost-controlled downtime, the incident will not automatically qualify for an SLA remedy.

14.1A service credit will apply only where the applicable service or order expressly includes a service-credit commitment.

14.2SKPHost does not promise automatic financial compensation for every service interruption.

14.3Where a service-credit schedule is expressly published for a particular service, eligibility will be determined according to that schedule and this SLA.

14.4Service credits are not cash refunds unless SKPHost expressly agrees otherwise or applicable law requires a different remedy.

14.5An approved service credit will normally be applied toward the affected Customer account or eligible service.

14.6A service credit does not create an entitlement to compensation for indirect losses, lost revenue or other consequential business losses. Any applicable liability remains subject to the SKPHost Terms & Conditions and mandatory law.

15.1Where a particular service includes an SLA credit, the Customer must submit the request through the SKPHost Support system.

15.2The request should identify the affected service, relevant date and approximate time, description of the interruption, and relevant evidence reasonably available to the Customer.

15.3SKPHost may verify the request against its own monitoring, logs and upstream-provider information.

15.4Submission of an SLA request does not automatically establish eligibility for a credit.

15.5SKPHost will determine whether the incident falls within the applicable service-credit commitment based on the technical cause, duration and exclusions contained in this SLA.

16.1SLA remedies will not normally apply to scheduled maintenance or reasonable emergency maintenance.

16.2They will not normally apply to Customer-controlled software or configuration, Customer DNS configuration, third-party applications or integrations, or Customer-generated resource exhaustion or abusive workloads.

16.3They will not normally apply to suspension or restriction permitted under applicable SKPHost policies, DDoS or security events outside available protection or reasonable control, external datacenter or upstream failures outside SKPHost’s reasonable control, or force majeure and comparable events.

16.4Other exclusions expressly disclosed for the applicable service will also apply.

17.1SKPHost provides different types of hosting and infrastructure services, and the same availability commitment may not be appropriate for every product.

17.2An SLA target or service-credit arrangement advertised for one service does not automatically apply to another service.

17.3Product-specific SLA terms, where provided, form part of this SLA for that product.

17.4Where no specific uptime percentage or service-credit schedule is expressly stated for a service, no particular numerical uptime or automatic credit commitment should be inferred.

18.1This SLA deals specifically with service availability and related SLA remedies.

18.2Account use, billing, Customer responsibilities, suspension, termination and other general service conditions remain governed by the SKPHost Terms & Conditions and applicable policies.

18.3Refund eligibility is governed separately by the SKPHost Refund Policy.

18.4Personal-information handling is governed separately by the SKPHost Privacy Policy.

18.5If a product-specific SLA expressly provides a different availability or service-credit condition, that specific condition will apply to that product to the extent of the stated difference, subject to applicable law.

19.1SKPHost may update this SLA to reflect changes in services, infrastructure, upstream providers, technology or applicable requirements.

19.2The current version will display its latest revision date.

19.3Material changes will be communicated where required by applicable law or the applicable service agreement.