Network Service Level Agreements

1. Purpose and Scope

This Service Level Agreement Policy explains the service-availability commitments, support expectations, maintenance rules, outage calculations, exclusions, service-credit procedures, and customer responsibilities that apply to eligible Spark Rack Services.

This Policy applies to:

1. Spark Rack hosting Services;
2. Virtual private servers;
3. Dedicated servers;
4. Managed servers;
5. Shared infrastructure;
6. Network Services;
7. Email Services;
8. DNS Services;
9. Storage Services;
10. Monitoring Services;
11. Managed Services;
12. Backup Services;
13. Customer Portal functions;
14. Support Services;
15. Any other Service expressly identified as eligible for a service-level commitment; and
16. Any Customer purchasing or using an eligible Service.

This Policy forms part of the Spark Rack Terms of Service. It must be read together with the applicable Order, Service description, Acceptable Use Policy, Data Backup and Restoration Policy, Privacy Policy, and any separately signed agreement.

2. Plain-Language Summary

Spark Rack works to keep its Services stable, available, secure, and responsive.

Technology can fail. Networks can be interrupted. Software can contain defects. Hardware can stop working. Security incidents can require emergency action. Third-party providers can experience outages. Maintenance sometimes requires temporary interruption.

This Policy establishes a measurable availability commitment for eligible Services, but it is not a promise that every Service will operate perfectly every second of every day.

When an eligible Service falls below the applicable monthly availability commitment for reasons within Spark Rack’s responsibility, an eligible Customer may request a Service Credit according to this Policy.

A Service Credit is the Customer’s sole and exclusive remedy for Spark Rack’s failure to meet an availability commitment unless a separately signed written agreement expressly provides another remedy.

3. Definitions

3.1 “Affected Service”

The specific paid Service that experienced qualifying Unavailability.

3.2 “Applicable Monthly Fee”

The recurring base Service fee charged for the Affected Service during the Measurement Month, excluding taxes, setup fees, usage charges, overages, licenses, domain fees, professional services, add-ons, third-party charges, restoration fees, and other nonrecurring charges.

3.3 “Availability”

The ability of an eligible Service to perform its primary intended function and be reasonably accessible through the applicable Spark Rack-controlled system.

3.4 “Business Hours”

Spark Rack’s published regular support hours, excluding published holidays and closures.

3.5 “Customer-Caused Event”

An interruption, degradation, or failure caused directly or indirectly by Customer, an End User, Customer software, Customer configuration, Customer Content, Customer credentials, Customer equipment, or a third party selected or controlled by Customer.

3.6 “Downtime”

The number of whole minutes during which an eligible Service experiences qualifying Unavailability after all exclusions in this Policy are applied.

3.7 “Emergency Maintenance”

Unplanned maintenance that Spark Rack reasonably determines is necessary to protect security, stability, data integrity, network integrity, regulatory compliance, or continued operation.

3.8 “Eligible Service”

A paid production Service expressly identified by Spark Rack as covered by an availability commitment.

3.9 “Measurement Month”

The calendar month, measured using Coordinated Universal Time, during which the claimed Downtime occurred, unless the applicable Order expressly establishes a different measurement period.

3.10 “Monthly Availability Percentage”

The percentage of eligible minutes during a Measurement Month in which the Affected Service was Available.

3.11 “Scheduled Maintenance”

Maintenance that Spark Rack plans in advance and performs to update, repair, replace, secure, migrate, or improve a Service or supporting system.

3.12 “Service Credit”

A noncash credit applied to a future invoice for the Affected Service according to this Policy.

3.13 “Support Response”

A meaningful acknowledgment by Spark Rack that a support request has been received and entered into the support process. A Support Response is not a promise that the issue has been resolved.

3.14 “Unavailability”

A condition in which an Eligible Service cannot perform its primary intended function because of a failure within the portion of the system controlled by Spark Rack.

4. Services Covered by This Policy

This Policy applies only to paid production Services that are identified as SLA-eligible in:

1. The applicable Order;
2. The Service description;
3. The Customer Portal;
4. A product-specific SLA;
5. A statement of work; or
6. A separately signed written agreement.

A Service is not covered merely because it is operated, hosted, monitored, supported, or made accessible by Spark Rack.

If the applicable Service description does not state that a Service is SLA-eligible, the Service is provided on a commercially reasonable and best-effort basis without a Service Credit commitment.

5. Services Not Covered by Default

Unless Spark Rack expressly states otherwise, the following are not SLA-eligible:

1. Free Services;
2. Trial Services;
3. Beta Services;
4. Preview Services;
5. Experimental features;
6. Development environments;
7. Demonstration systems;
8. Testing environments;
9. Temporary Services;
10. Courtesy Services;
11. Migration environments;
12. End-of-life Services;
13. Unsupported software;
14. Customer-managed applications;
15. Customer-controlled equipment;
16. Customer-controlled networks;
17. Third-party integrations;
18. Domain registration or registry availability;
19. External email delivery;
20. External DNS propagation;
21. Internet routes outside Spark Rack’s control;
22. Customer backup completion;
23. Data restoration success;
24. Data integrity;
25. Data retention;
26. Professional Services;
27. Consulting Services;
28. One-time work;
29. Customer-requested custom software;
30. Third-party software licenses; and
31. Any Service that is suspended, expired, terminated, unpaid, or past due.

6. Standard Availability Commitment

Unless the applicable Order or Service description states a different commitment, Spark Rack will use commercially reasonable efforts to provide each Eligible Service with a Monthly Availability Percentage of at least 99.9%.

The 99.9% commitment applies only to qualifying Unavailability measured according to this Policy.

The availability commitment does not mean that:

1. The Service will never experience an interruption;
2. The Service will always respond at the same speed;
3. Every feature will always be available;
4. Every third-party integration will always operate;
5. Every Internet user will always be able to reach the Service;
6. Every email will be delivered;
7. Every DNS resolver will return the same result immediately;
8. Every Customer application will operate correctly;
9. Every backup will complete;
10. Every restoration will succeed;
11. No data loss can occur; or
12. The Service is appropriate for life-safety or other failure-intolerant use.

7. Service-Specific Commitments

An Order, Service description, or separately signed agreement may establish a different availability percentage, support commitment, measurement method, credit schedule, or exclusion for a particular Service.

When a service-specific commitment conflicts with this general Policy, the service-specific commitment controls only for the specific Service and subject matter it addresses.

All provisions of this Policy that are not expressly replaced remain in effect.

8. No Implied SLA

No SLA commitment is created by:

1. A sales discussion;
2. An informal email;
3. A support response;
4. A statement made during troubleshooting;
5. A monitoring dashboard;
6. A status indicator;
7. A control-panel label;
8. A product comparison;
9. A marketing statement;
10. An estimate;
11. An expected completion time;
12. A target;
13. A past performance result;
14. An industry practice;
15. A third-party representation; or
16. Any statement not contained in an applicable written Spark Rack agreement or Service description.

9. Availability Calculation

The Monthly Availability Percentage is calculated as follows:

Monthly Availability Percentage = ((Eligible Minutes − Qualifying Downtime) ÷ Eligible Minutes) × 100

“Eligible Minutes” means the total number of minutes during the Measurement Month in which the Affected Service:

1. Was active;
2. Was paid and in good standing;
3. Was not suspended;
4. Was not terminated;
5. Was not undergoing excluded maintenance;
6. Was not affected by another exclusion in this Policy; and
7. Was otherwise eligible for SLA measurement.

Downtime is deducted only once, even when the same incident affects multiple components of one Service.

10. Minimum Outage Duration

An incident must cause at least five consecutive whole minutes of qualifying Unavailability before it is counted as Downtime.

Brief interruptions lasting less than five consecutive minutes do not qualify for Service Credit consideration.

After the initial five-minute threshold is reached, qualifying whole minutes within the continuous incident may be counted.

Repeated brief interruptions may be reviewed as one incident when Spark Rack determines that they resulted from the same underlying failure and materially prevented ordinary use of the Service.

11. Start and End of an Outage

Qualifying Downtime ordinarily begins when Spark Rack’s monitoring systems confirm that the Eligible Service has been continuously Unavailable for at least five minutes.

Qualifying Downtime ordinarily ends when Spark Rack’s monitoring systems confirm that the primary function of the Service has been restored and remains reasonably stable for at least five consecutive minutes.

Spark Rack may adjust the start or end time when reliable logs, monitoring data, or incident records show that a different time is more accurate.

12. Spark Rack Monitoring Is Authoritative

Spark Rack will determine Availability using information reasonably available from:

1. Internal monitoring systems;
2. External monitoring locations;
3. Network telemetry;
4. Server logs;
5. Application logs;
6. Hypervisor records;
7. Firewall records;
8. Storage records;
9. Data-center records;
10. Upstream-provider records;
11. Status-page records;
12. Support-ticket timestamps;
13. Incident-management records; and
14. Other reliable technical evidence.

Spark Rack’s records are authoritative for SLA calculations unless the Customer provides clear and reliable evidence showing a material error.

13. Customer Monitoring Evidence

A Customer may submit monitoring evidence with a Service Credit request.

Customer evidence should include:

1. The affected hostname, IP address, Service identifier, or Account;
2. The date and time of the incident;
3. The time zone used;
4. The monitoring location;
5. The monitoring method;
6. The frequency of monitoring checks;
7. The observed error;
8. Relevant logs;
9. Relevant screenshots;
10. Traceroutes where applicable;
11. Packet-loss results where applicable;
12. DNS results where applicable; and
13. Any other information reasonably necessary to evaluate the claim.

A single failed check, screenshot, browser message, or third-party status report does not by itself prove qualifying Unavailability.

14. Complete Unavailability

A Service generally experiences qualifying Unavailability when its primary intended function is completely inaccessible or unusable because of a failure within Spark Rack’s controlled environment.

Examples may include:

1. A hosted website cannot be reached from multiple independent networks because the Spark Rack hosting platform is offline;
2. A virtual server cannot run because the underlying Spark Rack-controlled host has failed;
3. A Spark Rack-operated DNS platform cannot answer authoritative queries from multiple external locations;
4. A Spark Rack-operated email platform cannot accept or provide mailbox access because the platform is offline;
5. A storage Service cannot be accessed because the applicable Spark Rack-controlled storage system has failed; or
6. A network Service cannot transmit traffic because the applicable Spark Rack-controlled network is unavailable.

15. Partial Degradation

Slowness, intermittent errors, partial feature failure, packet loss, increased latency, reduced throughput, or degradation may not qualify as Unavailability when the primary Service remains usable.

Spark Rack may treat severe degradation as Unavailability when:

1. The primary intended function is effectively unusable;
2. The condition is measurable;
3. The condition lasts at least five consecutive minutes;
4. The condition results from a failure within Spark Rack’s control; and
5. The condition is not subject to an exclusion.

Performance expectations that are not expressly defined in writing are objectives rather than guaranteed service levels.

16. Individual Feature Failure

The failure of an optional, secondary, cosmetic, administrative, reporting, or convenience feature does not constitute Unavailability when the primary Service remains operational.

Examples may include:

1. A reporting graph fails to display;
2. A nonessential dashboard widget is unavailable;
3. A cosmetic interface element is incorrect;
4. An optional integration is unavailable;
5. A nonessential notification is delayed;
6. A usage report is delayed;
7. A control-panel feature is temporarily unavailable while the hosted website remains online;
8. A password-reset email is delayed while Account access remains possible through another authorized method;
9. A nonessential API endpoint fails while the primary Service remains operational; or
10. An informational status page is unavailable while the underlying Service remains operational.

17. Customer Portal Availability

An interruption affecting the Customer Portal does not automatically mean that Customer hosting, servers, email, DNS, storage, or other production Services are Unavailable.

Similarly, an interruption affecting a production Service does not necessarily mean that the Customer Portal is Unavailable.

Customer Portal availability is measured separately and is covered only when expressly identified as an Eligible Service.

18. Shared Hosting Availability

For an eligible shared-hosting Service, Unavailability generally means that the Spark Rack-controlled hosting platform cannot serve Customer website traffic because of a platform, server, storage, or network failure.

Shared-hosting Unavailability does not include failure caused by:

1. Customer website code;
2. Customer themes or plugins;
3. Customer database queries;
4. Customer resource exhaustion;
5. Customer security settings;
6. Customer file permissions;
7. Customer DNS configuration;
8. Customer domain expiration;
9. Customer SSL configuration;
10. Unsupported software;
11. Malware within Customer Content;
12. Customer-requested changes;
13. Third-party APIs;
14. Content-delivery networks;
15. External databases;
16. External authentication providers; or
17. Other Customer-controlled dependencies.

19. Virtual Private Server Availability

For an eligible virtual private server, Unavailability generally means that the virtual machine cannot run or cannot access the Spark Rack-controlled network because of a failure of the underlying Spark Rack-controlled infrastructure.

Virtual private server Unavailability does not include failure caused by:

1. The guest operating system;
2. Customer firewall rules;
3. Customer routing rules;
4. Customer software;
5. Customer resource exhaustion;
6. Customer kernel changes;
7. Customer updates;
8. Customer reboots;
9. Customer shutdown commands;
10. Customer disk corruption;
11. Customer encryption;
12. Customer credentials;
13. Customer security compromise;
14. Unsupported operating systems;
15. Third-party licensing failures;
16. Customer-requested rescue or recovery work; or
17. Other conditions within the virtual machine.

20. Dedicated Server Availability

For an eligible dedicated server, Unavailability generally means that the server cannot be powered on or cannot access the Spark Rack-controlled network because of a covered hardware, power, data-center, or network failure.

Dedicated server Unavailability does not include:

1. Operating-system failure;
2. Application failure;
3. Customer configuration failure;
4. Customer firewall rules;
5. Customer-initiated shutdown;
6. Customer-requested maintenance;
7. Customer-installed hardware;
8. Unsupported hardware;
9. Customer-managed storage failure;
10. Customer-controlled remote-access failure;
11. Software licensing failure;
12. Malware;
13. Ransomware;
14. Customer-caused overload; or
15. Other failures outside Spark Rack’s managed scope.

21. Managed Service Availability

A managed Service covers only the components and responsibilities expressly identified as managed by Spark Rack.

The existence of a managed Service does not make Spark Rack responsible for every application, dependency, third-party provider, integration, configuration, business process, or Customer action.

Managed Service availability is measured only against the specific managed components stated in the applicable Order or Service description.

22. Network Availability

For an eligible network Service, Unavailability generally means that the applicable Spark Rack-controlled network cannot transmit traffic between the covered Service and Spark Rack’s external network edge.

Network Availability does not include:

1. The public Internet outside Spark Rack’s network;
2. Customer Internet connections;
3. Customer local-area networks;
4. Customer wireless networks;
5. Customer Internet service providers;
6. Remote-user connections;
7. External peering disputes;
8. External routing instability;
9. External route leaks;
10. External route hijacks;
11. Regional Internet congestion;
12. Governmental Internet blocking;
13. Third-party content-delivery networks;
14. Third-party proxy or VPN services;
15. Destination-network failures;
16. Remote-host failures; or
17. Any network segment outside Spark Rack’s reasonable control.

23. Packet Loss and Latency

Packet loss or latency does not automatically constitute Unavailability.

Internet performance can vary because of routing, distance, congestion, peering, remote networks, protocol behavior, traffic volume, and conditions outside Spark Rack’s control.

Packet loss or latency may be considered qualifying Downtime only when:

1. It occurs within Spark Rack’s controlled network;
2. It makes the primary Service effectively unusable;
3. It lasts at least five consecutive minutes;
4. It is confirmed by reliable monitoring; and
5. No exclusion applies.

24. DNS Availability

For an eligible Spark Rack-operated authoritative DNS Service, Unavailability generally means that the covered authoritative DNS platform fails to answer valid DNS queries from multiple independent networks.

DNS Unavailability does not include:

1. DNS propagation time;
2. Resolver caching;
3. Negative caching;
4. Customer DNS-record errors;
5. Missing DNS records;
6. Incorrect nameservers;
7. Domain expiration;
8. Domain suspension;
9. Registry failure;
10. Registrar failure;
11. DNSSEC misconfiguration;
12. Third-party resolver failure;
13. Internet-service-provider DNS failure;
14. Governmental DNS interference;
15. Customer-requested DNS changes; or
16. DNS systems operated outside Spark Rack’s control.

25. Domain Services

Domain registration, renewal, transfer, registry operation, WHOIS or registration-data services, and Internet-wide DNS propagation are not covered by the standard availability commitment.

Spark Rack does not control:

1. Domain registries;
2. Every registrar;
3. Registry maintenance;
4. Registry policies;
5. Transfer approval;
6. Registrant verification;
7. Dispute proceedings;
8. Domain suspension by a registry or registrar;
9. Domain seizure;
10. Internet-wide caching;
11. Third-party nameservers; or
12. External DNS resolvers.

26. Email Service Availability

For an eligible Spark Rack-operated email Service, Unavailability generally means that the covered email platform cannot accept authenticated user access or process messages because the Spark Rack-controlled email platform is offline.

Email Unavailability does not include:

1. Delayed delivery by a remote provider;
2. Rejection by a remote provider;
3. Spam-folder placement;
4. Recipient filtering;
5. Sender reputation;
6. Domain reputation;
7. IP reputation;
8. Blocklisting;
9. Incorrect SPF records;
10. Incorrect DKIM records;
11. Incorrect DMARC records;
12. Incorrect DNS records;
13. Mailbox quota exhaustion;
14. Customer email-client configuration;
15. Customer password problems;
16. Customer mailbox rules;
17. Message-size limits;
18. Attachment restrictions;
19. Malware filtering;
20. Spam filtering;
21. Rate limiting;
22. Abuse-prevention controls;
23. Third-party relay services;
24. Third-party mailbox providers;
25. Internet connectivity outside Spark Rack’s control; or
26. Messages delayed for security or policy review.

27. No Email Delivery Guarantee

Spark Rack does not guarantee that any particular email will:

1. Be accepted by a remote server;
2. Reach a recipient’s inbox;
3. Avoid a spam folder;
4. Be delivered within a particular period;
5. Be retained by a recipient’s provider;
6. Be displayed correctly by every email client;
7. Pass every external filtering system;
8. Avoid rate limiting;
9. Avoid blocklisting; or
10. Remain recoverable after deletion.

Email-delivery outcomes controlled by external providers are outside the standard SLA.

28. Storage Availability

For an eligible storage Service, Unavailability generally means that the covered Spark Rack-controlled storage platform cannot be accessed through its intended interface because of a failure within Spark Rack’s controlled environment.

Storage Availability does not guarantee:

1. Data integrity;
2. Data completeness;
3. Successful backup completion;
4. Successful restoration;
5. Recovery of deleted information;
6. Application consistency;
7. Database consistency;
8. Retention of every version;
9. Freedom from malware;
10. Freedom from corruption; or
11. Suitability for archival or regulatory purposes.

29. Backup Services

Backup and restoration Services are governed by the Spark Rack Data Backup and Restoration Policy.

An availability commitment for a backup platform does not guarantee:

1. That a backup job will complete;
2. That every item will be captured;
3. That every recovery point will be retained;
4. That a backup will be uncorrupted;
5. That a backup will be free from malware;
6. That a restoration will succeed;
7. That every file or record will be restored;
8. That an RPO will be met;
9. That an RTO will be met; or
10. That a backup will satisfy a compliance requirement.

30. Monitoring Services

A monitoring Service measures conditions according to its configured checks and available data.

Monitoring availability does not guarantee that the monitoring system will:

1. Detect every failure;
2. Detect every security incident;
3. Detect every performance issue;
4. Detect every missing file;
5. Detect every application error;
6. Detect every partial outage;
7. Send every notification;
8. Reach every recipient;
9. Identify the correct root cause;
10. Prevent an outage;
11. Prevent data loss; or
12. Guarantee compliance.

31. Redundant and High-Availability Services

A Service is considered redundant or highly available only when the applicable Service description expressly states that the required redundant architecture is included.

For a redundant Service, qualifying Unavailability generally occurs only when the complete covered Service becomes unavailable.

If at least one functioning covered endpoint, node, region, replica, or service path remains available and the primary Service continues to operate, the event may not qualify as Downtime.

Customer is responsible for using the provided redundancy correctly, including configuring:

1. Multiple endpoints;
2. Failover;
3. Health checks;
4. Load balancing;
5. DNS failover;
6. Application retries;
7. Database replication;
8. Multiple availability zones;
9. Multiple regions;
10. Data replication;
11. Credential access;
12. Firewall access; and
13. Other required Customer-controlled components.

32. Single-Instance Services

A single server, single virtual machine, single storage volume, single application instance, or single network path contains an inherent single point of failure.

Unless the applicable Service expressly includes redundancy, failover, or high availability, Spark Rack does not guarantee seamless continuation during:

1. Hardware failure;
2. Host failure;
3. Storage failure;
4. Operating-system failure;
5. Application failure;
6. Maintenance;
7. Migration;
8. Reboot;
9. Replacement;
10. Security remediation; or
11. Recovery work.

33. Customer Responsibility for Redundancy

Customer is responsible for determining whether Customer’s operations require:

1. Multiple servers;
2. Multiple data centers;
3. Multiple regions;
4. Multiple network providers;
5. Load balancing;
6. Automatic failover;
7. Database replication;
8. External backups;
9. Offline backups;
10. Immutable backups;
11. Secondary DNS;
12. Secondary email routing;
13. Alternate communication methods;
14. Alternate vendors;
15. Manual continuity procedures; or
16. Other resilience measures.

A Customer that requires greater resilience than the purchased Service provides must purchase or maintain appropriate additional systems.

34. Scheduled Maintenance

Scheduled Maintenance is excluded from Downtime.

Spark Rack may perform Scheduled Maintenance to:

1. Install security updates;
2. Install software updates;
3. Install firmware updates;
4. Replace hardware;
5. Replace storage;
6. Replace network equipment;
7. Upgrade capacity;
8. Improve performance;
9. Improve reliability;
10. Improve security;
11. Migrate systems;
12. Change data centers;
13. Change network providers;
14. Perform required testing;
15. Repair known defects; or
16. Perform other reasonable operational work.

35. Maintenance Notice

When commercially practical, Spark Rack will attempt to provide at least twenty-four hours’ notice before Scheduled Maintenance that is reasonably expected to cause a material interruption.

This notice period is a target and not a separate guaranteed service level.

Maintenance notice may be provided through:

1. The Customer Portal;
2. Email;
3. The Spark Rack status page;
4. A support ticket;
5. An Account notification;
6. An in-service notice; or
7. Another reasonable communication method.

Customer is responsible for maintaining accurate contact information and monitoring applicable Service notices.

36. Maintenance Windows

Spark Rack may establish regular or variable maintenance windows.

Maintenance may begin earlier, continue longer, or be rescheduled when reasonably necessary because of:

1. Unexpected technical conditions;
2. Hardware replacement delays;
3. Data migration duration;
4. Third-party provider delays;
5. Security concerns;
6. Testing requirements;
7. Rollback requirements;
8. Data integrity checks;
9. Staff safety;
10. Weather;
11. Facility access;
12. Supply-chain issues; or
13. Other operational conditions.

37. Emergency Maintenance

Emergency Maintenance is excluded from Downtime.

Spark Rack may perform Emergency Maintenance immediately and without advance notice when reasonably necessary to:

1. Address an active security threat;
2. Patch a critical vulnerability;
3. Stop data corruption;
4. Prevent hardware damage;
5. Protect network stability;
6. Contain malware;
7. Contain ransomware;
8. Mitigate a denial-of-service attack;
9. Respond to unauthorized access;
10. Comply with law;
11. Comply with a provider requirement;
12. Protect another Customer;
13. Prevent a wider outage;
14. Preserve evidence;
15. Protect personnel or property; or
16. Address another urgent operational risk.

38. Maintenance Requested by Customer

Downtime resulting from work requested, scheduled, approved, or initiated by Customer is excluded.

This includes:

1. Reboots;
2. Shutdowns;
3. Reinstallations;
4. Operating-system changes;
5. Software updates;
6. Application deployments;
7. Server migrations;
8. Data migrations;
9. DNS changes;
10. Firewall changes;
11. Storage changes;
12. Resource upgrades;
13. Resource downgrades;
14. Account transfers;
15. Security remediation;
16. Restoration work;
17. Testing;
18. Troubleshooting;
19. Custom development; or
20. Other Customer-approved work.

39. Security Actions

Downtime or degradation caused by reasonable security action is excluded.

Spark Rack may restrict, filter, isolate, rate limit, disable, suspend, reroute, or block Services when reasonably necessary to:

1. Protect the Spark Rack Network;
2. Protect Customer Data;
3. Protect another Customer;
4. Contain malware;
5. Contain ransomware;
6. Stop phishing;
7. Stop spam;
8. Stop unauthorized access;
9. Stop credential abuse;
10. Stop scanning;
11. Stop brute-force attacks;
12. Stop denial-of-service attacks;
13. Protect network reputation;
14. Protect IP reputation;
15. Protect email reputation;
16. Comply with the Acceptable Use Policy;
17. Comply with law;
18. Respond to an emergency; or
19. Prevent material harm.

40. Denial-of-Service Attacks

Downtime, packet loss, latency, filtering, null routing, blackholing, rate limiting, scrubbing, or other disruption caused by an actual or suspected denial-of-service attack is excluded.

Spark Rack may take protective action even when that action limits or temporarily prevents access to an Affected Service.

DDoS mitigation, when included, is provided on a reasonable-efforts basis and does not guarantee that:

1. Every attack will be detected;
2. Every attack will be mitigated;
3. No legitimate traffic will be affected;
4. No latency will be introduced;
5. The Service will remain continuously reachable;
6. No route will be withdrawn;
7. No IP address will be null routed;
8. No traffic will be rate limited; or
9. No manual intervention will be required.

41. Customer-Caused Events

Downtime caused directly or indirectly by Customer or an End User is excluded.

Examples include:

1. Incorrect configuration;
2. Incorrect DNS records;
3. Incorrect firewall rules;
4. Incorrect routing;
5. Incorrect file permissions;
6. Incorrect application settings;
7. Unsupported software;
8. Unpatched software;
9. Resource exhaustion;
10. Disk exhaustion;
11. Mailbox exhaustion;
12. Database exhaustion;
13. Excessive traffic;
14. Runaway processes;
15. Application deadlocks;
16. Customer code defects;
17. Customer database defects;
18. Customer credential compromise;
19. Customer malware infection;
20. Customer ransomware infection;
21. Customer deletion;
22. Customer shutdown;
23. Customer reboot;
24. Customer suspension of a Service;
25. Customer API misuse;
26. Customer interference with monitoring;
27. Customer failure to follow instructions;
28. Customer failure to cooperate with remediation; or
29. Any other Customer action or omission.

42. Resource Limits

Downtime or degradation caused by reaching, exceeding, or abusing a Service limit is excluded.

Service limits may include:

1. CPU limits;
2. Memory limits;
3. Storage limits;
4. Inode limits;
5. Database limits;
6. Mailbox limits;
7. Bandwidth limits;
8. Port-speed limits;
9. Connection limits;
10. Process limits;
11. API limits;
12. Rate limits;
13. Email-sending limits;
14. Recipient limits;
15. Backup limits;
16. Snapshot limits;
17. Account limits;
18. License limits;
19. Fair-use limits; and
20. Other technical or contractual limits.

43. Third-Party Services

Downtime caused by a third-party product, provider, platform, network, data center, registrar, registry, software vendor, carrier, API, or integration outside Spark Rack’s reasonable control is excluded.

Examples include:

1. Domain registries;
2. Domain registrars;
3. Certificate authorities;
4. Payment processors;
5. Software licensors;
6. Cloud providers;
7. Data-center providers;
8. Internet carriers;
9. Upstream network providers;
10. External DNS providers;
11. Content-delivery networks;
12. Email filtering providers;
13. Identity providers;
14. External authentication systems;
15. Customer-selected applications;
16. Customer-selected plugins;
17. Customer-selected APIs;
18. External databases;
19. External storage;
20. Remote destinations; or
21. Other third-party dependencies.

44. Upstream and Data-Center Commitments

Spark Rack may receive service commitments from upstream providers, carriers, data centers, software providers, or other vendors.

Those third-party commitments do not automatically become commitments from Spark Rack to Customer.

Customer is entitled only to the SLA expressly provided by Spark Rack for the applicable Service.

Spark Rack is not required to pass through a third-party credit unless a separately signed agreement expressly requires it.

45. Internet Conditions

Downtime or degradation caused by the public Internet outside Spark Rack’s controlled network is excluded.

This includes:

1. Regional Internet outages;
2. Remote carrier outages;
3. Remote peering failures;
4. Route leaks;
5. Route hijacks;
6. Congestion;
7. International cable failures;
8. Governmental filtering;
9. National Internet shutdowns;
10. Remote resolver failure;
11. Remote firewall failure;
12. Customer Internet failure;
13. Mobile-network failure;
14. Residential Internet failure;
15. Remote VPN failure;
16. Remote proxy failure;
17. Remote destination failure; or
18. Other conditions outside Spark Rack’s reasonable control.

46. Force Majeure and Extraordinary Events

Downtime caused by circumstances outside Spark Rack’s reasonable control is excluded.

Examples include:

1. Fire;
2. Flood;
3. Hurricane;
4. Tornado;
5. Earthquake;
6. Lightning;
7. Severe weather;
8. Natural disaster;
9. Utility failure;
10. Regional power-grid failure;
11. Telecommunications failure;
12. War;
13. Terrorism;
14. Civil unrest;
15. Sabotage;
16. Labor dispute;
17. Pandemic;
18. Epidemic;
19. Governmental action;
20. Court order;
21. Sanctions;
22. Embargo;
23. Supply-chain disruption;
24. Hardware shortage;
25. Carrier-wide outage;
26. Cloud-provider outage;
27. Data-center evacuation;
28. Cyberattack;
29. Ransomware;
30. Zero-day vulnerability;
31. Internet-wide protocol failure; or
32. Any other event Spark Rack could not reasonably prevent or overcome.

47. Legal and Regulatory Actions

Downtime caused by legal, regulatory, governmental, law-enforcement, registry, registrar, court, or provider action is excluded.

This includes:

1. Service suspension required by law;
2. Domain suspension;
3. Domain seizure;
4. IP-address blocking;
5. Route withdrawal;
6. Preservation orders;
7. Search warrants;
8. Subpoenas;
9. Court orders;
10. Sanctions restrictions;
11. Export restrictions;
12. Registry requirements;
13. Registrar requirements;
14. Data-center compliance action;
15. Carrier compliance action; or
16. Other legally required restrictions.

48. Acceptable Use Enforcement

Downtime caused by suspension, restriction, filtering, isolation, rate limiting, null routing, or termination under the Acceptable Use Policy is excluded.

A Customer is not entitled to a Service Credit for interruption resulting from:

1. Spam;
2. Phishing;
3. Malware;
4. Ransomware;
5. Fraud;
6. Denial-of-service activity;
7. Unauthorized scanning;
8. Credential attacks;
9. Copyright infringement;
10. Illegal content;
11. Child exploitation;
12. Network abuse;
13. Payment abuse;
14. Resource abuse;
15. Security risk;
16. Failure to respond to an abuse notice; or
17. Any other policy violation.

49. Billing Suspension and Nonpayment

A Service is not SLA-eligible while:

1. An invoice is overdue;
2. The Account is past due;
3. A payment is reversed;
4. A payment is disputed;
5. A payment method fails;
6. The Service is suspended;
7. The Service is expired;
8. The Service is pending cancellation;
9. The Service is terminated;
10. The Service is awaiting fraud review; or
11. The Account is otherwise not in good standing.

50. Support Services

Spark Rack provides support according to the Customer’s purchased Service plan, published support channels, and applicable support scope.

Support may include:

1. Incident acknowledgment;
2. Basic troubleshooting;
3. Service-status confirmation;
4. Configuration review;
5. Log review;
6. Escalation;
7. Provider coordination;
8. Security guidance;
9. Restoration assistance;
10. Managed administration;
11. Professional Services; or
12. Other assistance included in the applicable Service.

The availability of support does not mean that all work is included without additional charge.

51. Support Severity Levels

Severity	Description
Severity 1 — Critical	A paid production Service is completely unavailable to all or substantially all authorized users, or an active security incident creates an immediate and material risk.
Severity 2 — High	A major production function is unavailable or severely degraded, but a workaround or partial service remains available.
Severity 3 — Normal	A noncritical function is impaired, a limited number of users are affected, or ordinary technical assistance is required.
Severity 4 — Low	A question, informational request, feature request, cosmetic issue, documentation matter, or planned change.

52. Severity Classification

Customer may suggest a severity when submitting a request, but Spark Rack determines the final severity based on the actual technical and operational impact.

Spark Rack may change a ticket’s severity when:

1. The reported impact is inaccurate;
2. A workaround is available;
3. The Service is not completely unavailable;
4. The problem is outside Spark Rack’s scope;
5. The issue is caused by Customer;
6. The issue is a feature request;
7. The issue is a billing question;
8. The issue requires planned work;
9. The issue is resolved but follow-up remains;
10. The Customer stops responding; or
11. New technical information changes the assessment.

53. Support Response Targets

Support response targets are governed by the applicable Service plan or Order.

Unless expressly identified as guaranteed response times, published support response times are operational targets rather than SLA commitments.

A Support Response may consist of:

1. Acknowledgment of the issue;
2. A request for additional information;
3. Confirmation that an investigation has begun;
4. Confirmation that the matter has been escalated;
5. Identification of a known incident;
6. Provision of a workaround;
7. Referral to documentation;
8. Scheduling of required work; or
9. Another meaningful response.

54. Response Time Is Not Resolution Time

A response-time target measures the time until Spark Rack meaningfully acknowledges or begins handling a support request.

It is not a guarantee that:

1. The issue will be resolved within the response period;
2. The cause will be identified immediately;
3. A workaround will be available;
4. A software patch will be available;
5. Replacement hardware will be immediately available;
6. A third-party provider will respond within the same period;
7. Data will be restored within the same period;
8. Customer action will not be required;
9. The issue is within Spark Rack’s responsibility; or
10. The requested change is included in the Service.

55. No Guaranteed Resolution Time

Unless a separately signed written agreement expressly provides a guaranteed resolution time, Spark Rack does not guarantee that any incident will be resolved within a specific period.

Resolution time may depend on:

1. Incident complexity;
2. Customer cooperation;
3. Customer response time;
4. Access to affected systems;
5. Availability of logs;
6. Availability of backups;
7. Availability of replacement hardware;
8. Availability of software updates;
9. Availability of vendor support;
10. Third-party response;
11. Data volume;
12. Security investigation;
13. Legal restrictions;
14. Maintenance requirements;
15. Testing requirements;
16. Risk of additional damage; and
17. Other technical or operational conditions.

56. Emergency Support

Twenty-four-hour emergency support is included only when expressly stated in the applicable Service plan or Order.

Emergency support is intended for genuine Severity 1 incidents.

The following ordinarily do not qualify as emergencies:

1. General questions;
2. Feature requests;
3. Routine configuration changes;
4. Password changes when another authorized recovery method is available;
5. Website-design issues;
6. Cosmetic issues;
7. Customer code errors;
8. Customer deployment requests;
9. Planned migrations;
10. Billing questions;
11. Domain-propagation questions;
12. Email deliverability questions;
13. Unsupported software;
14. Nonproduction systems;
15. Development environments;
16. Trial Services; or
17. Issues that do not materially prevent production use.

57. Customer Cooperation

Customer must reasonably cooperate with investigation and remediation.

Customer cooperation may include:

1. Providing accurate information;
2. Providing timestamps;
3. Providing error messages;
4. Providing logs;
5. Providing screenshots;
6. Providing traceroutes;
7. Providing affected usernames or Service identifiers;
8. Providing secure temporary access;
9. Testing a proposed fix;
10. Approving a reboot;
11. Approving maintenance;
12. Updating software;
13. Removing unsupported software;
14. Correcting configuration;
15. Rotating credentials;
16. Stopping abusive traffic;
17. Responding to security questions;
18. Responding within a reasonable period; and
19. Following reasonable technical instructions.

Time during which Spark Rack is waiting for required Customer information, approval, access, testing, or action is not counted against a support response or restoration target.

58. Unsupported and End-of-Life Software

Incidents involving unsupported, unlicensed, modified, abandoned, or end-of-life software are excluded from SLA commitments.

Spark Rack may require Customer to:

1. Upgrade the software;
2. Replace the software;
3. Remove the software;
4. Purchase vendor support;
5. Provide valid licensing;
6. Restore a supported configuration;
7. Move to a supported platform; or
8. Accept best-effort support without an SLA.

59. Service Credit Schedule

Unless a Service-specific SLA provides a different schedule, an eligible Customer may receive the following Service Credit:

Monthly Availability Percentage	Service Credit
99.900% or greater	No Service Credit
Less than 99.900% but at least 99.000%	5% of the Applicable Monthly Fee
Less than 99.000% but at least 95.000%	10% of the Applicable Monthly Fee
Less than 95.000%	25% of the Applicable Monthly Fee

60. Maximum Service Credit

The maximum Service Credit for an Affected Service during one Measurement Month is twenty-five percent of the Applicable Monthly Fee unless a Service-specific SLA expressly provides a different maximum.

Service Credits do not:

1. Exceed the fee paid for the Affected Service;
2. Apply to unaffected Services;
3. Apply to future months;
4. Apply to taxes;
5. Apply to setup fees;
6. Apply to domain fees;
7. Apply to license fees;
8. Apply to usage charges;
9. Apply to overages;
10. Apply to professional services;
11. Apply to third-party charges;
12. Apply to restoration charges;
13. Apply to hardware purchases; or
14. Create a cash-refund entitlement.

61. One Credit Per Incident

A single incident does not create multiple overlapping Service Credits for the same Affected Service.

If one incident causes multiple symptoms, failures, alerts, support tickets, or component outages within the same Service, the incident is treated as one event for credit purposes.

If separately billed Eligible Services are independently unavailable, Spark Rack may calculate each affected Service separately.

62. No Stacking of Remedies

A Customer may not combine, stack, or duplicate:

1. Multiple SLA credits for the same incident;
2. A general SLA credit and a Service-specific credit for the same incident;
3. A Service Credit and a refund for the same Service period;
4. A Service Credit and a backup-related credit for the same event;
5. A Service Credit and a third-party pass-through credit for the same event; or
6. Multiple contractual remedies for the same availability failure unless expressly permitted in writing.

63. Service Credit Is Not Cash

Service Credits:

1. Are not cash;
2. Are not refundable;
3. Are not transferable;
4. Cannot be sold;
5. Cannot be exchanged;
6. Cannot be withdrawn;
7. Cannot be applied to another Customer’s Account;
8. Cannot be used to pay taxes;
9. Cannot be used to pay third-party fees; and
10. Have no value after Account closure.

An approved Service Credit will ordinarily be applied to a future invoice for the same Account.

64. Service Credit Request Deadline

Customer must submit a Service Credit request no later than fifteen calendar days after the end of the Measurement Month in which the claimed Downtime occurred.

A request submitted after the deadline may be denied.

Spark Rack is not required to issue Service Credits automatically.

65. Required Credit Request Information

A Service Credit request must include:

1. The Customer’s name;
2. The Account identifier;
3. The Affected Service;
4. The Service identifier, hostname, or IP address;
5. The date of the incident;
6. The approximate start time;
7. The approximate end time;
8. The time zone used;
9. A description of the observed Unavailability;
10. The relevant support-ticket number;
11. Any Customer monitoring evidence;
12. Any relevant logs or screenshots; and
13. A clear request for SLA review and Service Credit.

Spark Rack may request additional information reasonably necessary to evaluate the claim.

66. Support Ticket Requirement

Except during a known network-wide incident, Customer must report apparent Unavailability through an approved Spark Rack support channel while the incident is occurring or as soon as reasonably possible.

Prompt reporting allows Spark Rack to:

1. Confirm the incident;
2. Determine its scope;
3. Preserve relevant logs;
4. Begin troubleshooting;
5. Identify Customer-specific causes;
6. Coordinate with providers;
7. Reduce further impact; and
8. Accurately measure Downtime.

Failure to report an incident promptly may result in denial of a credit when Spark Rack cannot reasonably confirm the claimed Unavailability.

67. Credit Review

Spark Rack will review a timely and complete Service Credit request using available technical and Account records.

Spark Rack may:

1. Approve the request;
2. Approve part of the request;
3. Deny the request;
4. Request additional information;
5. Correct the claimed outage period;
6. Apply an exclusion;
7. Reclassify the affected Service;
8. Determine that the incident was Customer-caused;
9. Determine that the Service was not SLA-eligible; or
10. Determine that the availability threshold was met.

Spark Rack’s good-faith determination is final unless a separately signed agreement provides a formal appeal process.

68. Credit Eligibility Requirements

To receive a Service Credit, Customer must:

1. Have an active paid Eligible Service;
2. Have been in good standing during the incident;
3. Have paid all undisputed invoices when due;
4. Have complied with the Terms of Service;
5. Have complied with the Acceptable Use Policy;
6. Have used the Service in a supported configuration;
7. Have submitted a timely request;
8. Have provided reasonably complete information;
9. Have reasonably cooperated with investigation;
10. Have experienced qualifying Unavailability;
11. Have fallen below the applicable Monthly Availability Percentage; and
12. Not be subject to an exclusion.

69. Reasons a Credit May Be Denied

A Service Credit may be denied when:

1. The Service was not SLA-eligible;
2. The Service was free, trial, beta, preview, or experimental;
3. The availability commitment was met;
4. The interruption lasted less than five consecutive minutes;
5. The interruption was Scheduled Maintenance;
6. The interruption was Emergency Maintenance;
7. The interruption was Customer-caused;
8. The interruption was caused by a third party;
9. The interruption was caused by the public Internet;
10. The interruption was caused by a security action;
11. The interruption was caused by DDoS activity;
12. The interruption was caused by policy enforcement;
13. The interruption was caused by nonpayment or suspension;
14. The interruption affected only an optional feature;
15. The Service remained materially usable;
16. The request was late;
17. The request lacked required information;
18. The claimed incident could not be verified;
19. The Customer failed to cooperate;
20. The Customer used unsupported software;
21. The Customer exceeded a resource limit;
22. The Customer interfered with monitoring;
23. The Account was not in good standing; or
24. Another exclusion applies.

70. Incidents Spanning Multiple Months

If one qualifying incident spans more than one Measurement Month, availability and Service Credits are calculated separately for each affected month.

Customer must submit a timely request for each affected Measurement Month unless Spark Rack agrees to process the months together.

71. Partial-Month Services

If an Eligible Service is active for only part of a Measurement Month, availability is calculated using only the eligible minutes during which the Service was active and covered.

Minutes before provisioning, after cancellation, during suspension, or after termination are not included.

72. Service Migrations

Downtime during an approved Service migration is excluded unless the applicable migration agreement expressly states otherwise.

Migrations may involve:

1. DNS changes;
2. IP-address changes;
3. Data copying;
4. Database synchronization;
5. Application testing;
6. Certificate reissuance;
7. Email rerouting;
8. Cache expiration;
9. Network changes;
10. Customer testing;
11. Rollback procedures; and
12. Temporary interruption.

Customer must maintain independent backups and a rollback plan appropriate to the migration.

73. Status Communications

During a material incident, Spark Rack may provide updates through:

1. The Spark Rack status page;
2. The Customer Portal;
3. Email;
4. Support tickets;
5. Account notices;
6. Public notices; or
7. Another reasonable channel.

Status updates may be delayed while personnel focus on containment, safety, restoration, provider coordination, investigation, or verification.

An estimated restoration time is an estimate and not a guarantee.

74. Incident Updates

Spark Rack will attempt to provide useful updates during a confirmed material incident when commercially reasonable.

Updates may include:

1. Confirmation that an incident exists;
2. The affected Service category;
3. The approximate scope;
4. Actions being taken;
5. Known workarounds;
6. Estimated next-update timing;
7. Confirmation of restoration; or
8. Other information appropriate to the circumstances.

Spark Rack may withhold details that could:

1. Create a security risk;
2. Expose confidential information;
3. Identify another Customer;
4. Compromise an investigation;
5. Violate law;
6. Violate a provider agreement;
7. Mislead Customers before facts are confirmed; or
8. Interfere with recovery.

75. Post-Incident Reviews

After a significant incident, Spark Rack may perform an internal post-incident review.

When commercially reasonable, Spark Rack may provide affected Customers with a general incident summary.

A post-incident summary may include:

1. A general description of the incident;
2. The approximate incident period;
3. The affected Service category;
4. The general cause;
5. Actions taken to restore Service;
6. Corrective actions planned; and
7. Other appropriate information.

Spark Rack is not required to disclose:

1. Confidential security information;
2. Detailed network diagrams;
3. Exploit details;
4. Credentials;
5. Another Customer’s information;
6. Privileged legal analysis;
7. Confidential provider information;
8. Information restricted by law; or
9. Information that could increase future security risk.

76. No Root-Cause Guarantee

Spark Rack will make reasonable efforts to investigate material incidents, but it may not always be possible to identify a single or definitive root cause.

Complex incidents may involve:

1. Multiple failures;
2. Intermittent conditions;
3. Incomplete logs;
4. Third-party systems;
5. External networks;
6. Customer systems;
7. Unknown software defects;
8. Hardware defects;
9. Security threats;
10. Human error;
11. Correlated failures; or
12. Evidence unavailable after recovery.

77. Changes and Service Improvements

Spark Rack may modify systems, providers, software, hardware, networks, monitoring methods, maintenance processes, or Service architecture to improve security, reliability, capacity, functionality, or cost efficiency.

Spark Rack may:

1. Replace hardware;
2. Replace software;
3. Replace vendors;
4. Change data centers;
5. Change network providers;
6. Change IP addresses;
7. Change storage systems;
8. Change monitoring systems;
9. Change maintenance procedures;
10. Migrate workloads;
11. Retire obsolete features;
12. Change Service limits;
13. Change support procedures; or
14. Make other reasonable operational changes.

78. Customer Continuity Planning

Customer must maintain a continuity plan appropriate to Customer’s operations and risk.

The plan should consider:

1. Temporary Service interruption;
2. Extended Service interruption;
3. Loss of Internet connectivity;
4. Loss of email;
5. Loss of DNS;
6. Loss of a server;
7. Loss of a data center;
8. Loss of a third-party provider;
9. Loss of credentials;
10. Loss of Customer data;
11. Cyberattack;
12. Ransomware;
13. Hardware failure;
14. Application failure;
15. Manual business procedures;
16. Alternate communication methods;
17. Alternate infrastructure;
18. Independent backups;
19. Customer and employee notification;
20. Regulatory notification;
21. Vendor coordination; and
22. Recovery priorities.

79. High-Risk and Life-Safety Use

Unless Spark Rack expressly agrees in a separately signed written agreement, the Services are not designed or warranted for use where interruption, delay, error, or failure could reasonably result in:

1. Death;
2. Personal injury;
3. Loss of emergency communications;
4. Failure of medical care;
5. Failure of life-support systems;
6. Failure of emergency dispatch;
7. Failure of aviation systems;
8. Failure of transportation control;
9. Failure of industrial safety systems;
10. Failure of utility control systems;
11. Failure of public warning systems;
12. Catastrophic environmental damage;
13. Catastrophic financial loss; or
14. Another consequence requiring uninterrupted, failure-proof operation.

80. No Guarantee of Regulatory Compliance

Spark Rack does not represent or warrant that an SLA, availability percentage, support target, maintenance process, backup system, or Service Credit will make Customer compliant with any law, regulation, contract, insurance requirement, audit standard, or industry framework.

Customer is responsible for determining:

1. Which requirements apply;
2. Whether the purchased Service is appropriate;
3. Whether greater availability is required;
4. Whether geographic redundancy is required;
5. Whether automatic failover is required;
6. Whether independent monitoring is required;
7. Whether a higher support plan is required;
8. Whether a separately negotiated SLA is required;
9. Whether additional insurance is required; and
10. Whether additional technical or organizational safeguards are required.

81. No Data Guarantee

An availability commitment concerns access to an Eligible Service. It does not guarantee:

1. Data completeness;
2. Data accuracy;
3. Data integrity;
4. Data retention;
5. Backup completion;
6. Backup integrity;
7. Restoration success;
8. Recovery of deleted information;
9. Recovery of corrupted information;
10. Freedom from malware;
11. Freedom from ransomware;
12. Application consistency;
13. Database consistency;
14. Legal-record preservation; or
15. Compliance with a retention requirement.

82. No Absolute Availability Guarantee

No Spark Rack Service should be treated as guaranteed to operate without interruption, error, delay, degradation, maintenance, security action, or failure.

Even well-designed systems with monitoring, redundancy, backups, security controls, replacement hardware, and skilled personnel can experience unexpected failures.

The SLA establishes a measurable commitment and credit process. It does not make any Service infallible.

83. No Warranty Beyond the SLA

Except for the express commitments in this Policy or a separately signed written agreement, Services are provided according to the warranty disclaimers in the Terms of Service.

Spark Rack does not provide an implied warranty that:

1. The Service will be continuously available;
2. The Service will be error-free;
3. The Service will meet every Customer requirement;
4. Every incident will be detected;
5. Every incident will be resolved;
6. Every incident will be resolved within a particular time;
7. No data loss will occur;
8. No security incident will occur;
9. Every third-party service will remain available;
10. Every email will be delivered;
11. Every DNS request will resolve immediately;
12. Every backup will succeed;
13. Every restoration will succeed; or
14. The Service will satisfy every compliance obligation.

84. Limitation of Liability

The limitations of liability in the Spark Rack Terms of Service apply fully to this Policy.

To the maximum extent permitted by Applicable Law, Spark Rack is not liable for indirect, incidental, special, exemplary, punitive, or consequential losses arising from Service interruption, including:

1. Lost profits;
2. Lost revenue;
3. Lost business;
4. Lost opportunities;
5. Lost customers;
6. Loss of goodwill;
7. Loss of reputation;
8. Loss of data;
9. Cost of reconstructing data;
10. Cost of replacement services;
11. Business interruption;
12. Employee downtime;
13. Customer claims;
14. Contractual penalties;
15. Regulatory penalties;
16. Insurance deductibles;
17. Emergency vendor costs;
18. Travel costs;
19. Professional fees; or
20. Any other downstream loss.

85. Sole and Exclusive Remedy

An approved Service Credit under this Policy is Customer’s sole and exclusive remedy for Spark Rack’s failure to meet an availability commitment.

This does not limit a remedy that Applicable Law does not permit Spark Rack to exclude.

This does not create any remedy for:

1. A Service that is not SLA-eligible;
2. An excluded event;
3. Failure to meet an operational target;
4. Failure to meet an estimated completion time;
5. Failure to deliver an email;
6. Failure of a backup;
7. Failure of a restoration;
8. Failure of a third party;
9. Failure caused by Customer;
10. Loss of data; or
11. Another matter outside the express SLA commitment.

86. No Automatic Termination Right

Failure to meet an SLA commitment does not automatically permit Customer to terminate an Order, cancel a minimum term, avoid valid charges, or receive a refund.

Any termination right based on repeated availability failure must be expressly stated in a separately signed written agreement.

87. Policy Changes

Spark Rack may update this Policy to reflect:

1. Changes in technology;
2. Changes in Service architecture;
3. Changes in Service offerings;
4. Changes in providers;
5. Changes in monitoring;
6. Changes in maintenance practices;
7. Changes in security threats;
8. Changes in law;
9. Changes in operational experience;
10. Changes in support procedures;
11. Changes in credit procedures;
12. Clarifications; or
13. Other legitimate business or technical developments.

Changes apply prospectively unless Applicable Law permits or requires another application.

A change will not reduce a Service Credit already earned and timely requested for a Measurement Month completed before the change took effect.

88. Conflict With Other Documents

If this Policy conflicts with a Service-specific SLA or separately signed written agreement, the more specific document controls only for the particular Service and subject matter it addresses.

Marketing materials, informal statements, status messages, and support communications do not override this Policy.

89. No Waiver

Spark Rack’s decision to provide assistance, compensation, a courtesy credit, an extended response, or another accommodation does not:

1. Admit liability;
2. Establish qualifying Downtime;
3. Create a continuing obligation;
4. Modify this Policy;
5. Waive an exclusion;
6. Waive the credit-request deadline;
7. Create a precedent for another incident; or
8. Require Spark Rack to provide the same accommodation again.

90. Severability

If any provision of this Policy is found invalid or unenforceable, that provision will be modified or severed only to the minimum extent necessary.

The remaining provisions will continue in effect.

The invalidity of one provision does not create:

1. An absolute uptime guarantee;
2. An unlimited Service Credit;
3. A cash-refund right;
4. A data-loss guarantee;
5. A guaranteed resolution time;
6. A guarantee against third-party failure; or
7. A remedy beyond what Applicable Law requires.

91. Contact and Service Credit Requests

Support requests, outage reports, and Service Credit requests must be submitted through the appropriate support, billing, account, or service-management channel in the Spark Rack Customer Portal.

Written correspondence may be mailed to:

Spark Rack
Attn: Service Level Review
PO Box 2215
Valdosta, GA 31604
United States

Mailing a request does not extend the Service Credit request deadline.

92. Customer Acknowledgment

By ordering, accessing, or using a Spark Rack Service, Customer acknowledges and agrees that:

1. Only Services expressly identified as SLA-eligible are covered by an availability commitment.
2. The standard availability commitment for an Eligible Service is 99.9% per Measurement Month unless a different written commitment applies.
3. Availability is calculated only after the exclusions in this Policy are applied.
4. Scheduled Maintenance and Emergency Maintenance are excluded.
5. Customer-caused failures are excluded.
6. Third-party failures and public Internet conditions outside Spark Rack’s control are excluded.
7. Security actions, DDoS mitigation, and Acceptable Use Policy enforcement are excluded.
8. Partial degradation does not always constitute Unavailability.
9. Response time is not the same as resolution time.
10. No resolution time is guaranteed unless expressly stated in a separately signed written agreement.
11. Email delivery to an external provider is not guaranteed.
12. DNS propagation and domain-registry operation are not guaranteed.
13. Backup completion, data integrity, and restoration success are not guaranteed by this SLA.
14. Customer must maintain independent backups and continuity plans.
15. Customer must use supported configurations and remain within applicable resource limits.
16. Customer must report incidents promptly and cooperate with troubleshooting.
17. Service Credits must be requested within fifteen calendar days after the applicable Measurement Month.
18. Service Credits are noncash, nontransferable credits applied to a future invoice.
19. The maximum standard Service Credit is twenty-five percent of the Applicable Monthly Fee.
20. An approved Service Credit is the sole and exclusive remedy for failure to meet an availability commitment.
21. No technology provider can guarantee that every Service will operate perfectly or without interruption under every circumstance.
22. The SLA is a measurable commitment and credit process, not a promise of infallibility.