Service Level Agreement (SLA)

Last Updated: May 12, 2026

This Service Level Agreement ("SLA") sets forth the performance standards for {{COMPANY_NAME}}'s enterprise-grade multi-tenant platform.

1. DEFINITIONS AND METRICS

1.1. Incorporation and Scope

This Service Level Agreement ("SLA") is incorporated by reference into the master Terms of Service ("ToS") entered into between the Provider and the Customer. This SLA applies exclusively to the overarching availability of the Customer's public-facing digital storefront and core API capabilities (the "Data Plane"). It does not apply to the administrative Control Plane dashboard, staging environments, or third-party integrations.

1.2. Operational Definitions

To ensure an objective and mathematically verifiable standard for service availability, the following definitions shall apply:

  1. Measurement Period: A standard calendar month, beginning at 00:00
    UTC on the first day of the month and ending at 23:59
    UTC on the last day of the month.
  2. Total Monthly Minutes: The total number of minutes in the applicable Measurement Period (e.g., a 30-day month contains 43,200 minutes).
  3. Downtime: A verifiable period of system-wide unavailability or severe functional degradation, measured in full minutes, during which the Customer's Data Plane is commercially incapable of serving web traffic or processing End-Consumer checkout API requests. Downtime is triggered only when the Data Plane experiences a continuous, uninterrupted HTTP 5XX server error rate exceeding 5% of all traffic, or when the server response time (Time To First Byte - TTFB) continuously exceeds fifteen (15) seconds, for a minimum of five (5) consecutive minutes.

1.3. Exclusions from the Definition of "Downtime"

For the avoidance of doubt, "Downtime" strictly evaluates the core availability of the Provider's Kubernetes infrastructure and routing layers. The following scenarios are explicitly excluded from the calculation of Downtime:

  1. Non-Critical Degraded Performance: Periods of minor latency or slow page-load times that remain within commercially reasonable operational parameters (i.e., server response times under the 15-second critical threshold defined in Section 1.2) and do not result in continuous HTTP 5XX errors.
  2. Feature-Specific Bugs: Minor visual anomalies, CSS rendering issues, or the failure of a non-critical feature (e.g., a broken image carousel) that does not completely prevent an End-Consumer from navigating the storefront or completing a checkout.
  3. Third-Party Outages: Failures originating from external services integrated into the storefront (e.g., the storefront fails to load or experiences extreme latency because a Customer's external tracking script, custom font network, or third-party analytics tool is unreachable).

1.4. Monthly Uptime Percentage Formula

The "Monthly Uptime Percentage" is calculated mathematically for each Measurement Period using the following formula:

Monthly Uptime Percentage = ((Total Monthly Minutes - Total Minutes of Downtime) / Total Monthly Minutes) x 100

All calculations shall primarily be based on the Provider’s internal server logs, Kubernetes health-check metrics, and automated monitoring systems, subject to the evidence and dispute provisions set forth in Chapter 5 of this SLA.

2. THE SERVICE LEVEL COMMITMENT

2.1. The 99.5% Availability Target

The Provider is committed to delivering a highly reliable, enterprise-grade e-commerce infrastructure. The Provider shall use commercially reasonable efforts to ensure that the Customer's Data Plane achieves a Monthly Uptime Percentage of at least 99.5% during any given Measurement Period (the "Service Level Commitment").

2.2. Failure to Meet the Commitment

In the event the Provider does not meet this Service Level Commitment during a specific calendar month, the Customer shall become eligible to claim Service Credits, strictly subject to the reporting procedures, limitations, and exclusions defined in the subsequent chapters of this SLA.

3. DOWNTIME EXCLUSIONS

3.1. General Exclusions

To accurately calculate the Monthly Uptime Percentage, any period of Data Plane unavailability resulting directly or indirectly from the following categories shall be formally excluded from the calculation of "Downtime" and shall not count against the Service Level Commitment:

3.2. Maintenance Windows

  1. Scheduled Maintenance: Routine updates to the Kubernetes cluster, database migrations, or infrastructure scaling events. The Provider shall notify the Customer of any Scheduled Maintenance that may result in Data Plane unavailability at least forty-eight (48) hours in advance via the Control Plane dashboard or email. Scheduled maintenance is strictly limited to a maximum of four (4) hours per month and will typically be executed during off-peak periods (e.g., between 01
    and 05
    CET).
  2. Emergency Maintenance: Unplanned, critical interventions required to deploy immediate security patches (e.g., mitigating a zero-day vulnerability) or to prevent imminent hardware failure. The Provider reserves the right to execute Emergency Maintenance without prior notice to protect the overarching Shared Infrastructure.

3.3. Customer-Induced Failures

  1. Code and Configuration Errors: Outages caused by the Customer uploading incompatible custom themes, buggy HTML/JS snippets, malformed API payloads, or misconfiguring their custom domain's DNS records.
  2. Quota and Limit Exhaustion: Unavailability resulting from the Customer exceeding their allocated subscription limits, such as network egress quotas, API rate limits, or concurrent database connection caps defined in the master Terms of Service.
  3. AUP Enforcement: Any suspension or quarantine of the Data Plane executed by the Provider to enforce the Acceptable Use Policy (e.g., pausing the storefront due to suspected fraud, intellectual property infringement, or malicious activity).

3.4. External Network and Third-Party API Failures

Note: For the avoidance of doubt, failures of the Provider’s primary hosting sub-processor (e.g., OVHcloud) are not excluded. The Provider assumes responsibility for the overarching availability of its contracted infrastructure vis-à-vis the Customer. The following external failures are, however, excluded:

  1. Payment Gateway Failures: The inability of End-Consumers to complete checkout due to latency or downtime originating from integrated third-party payment processors (e.g., Stripe, Payplug, PayPal).
  2. External Integrations: Failures or severe latency caused by third-party systems connected to the storefront by the Customer (e.g., ERP sync failures, external CRM APIs, or broken tracking scripts).
  3. Internet Backbone and ISP Issues: Routing failures, DNS propagation delays, or ISP outages occurring on the public internet, outside the Provider's and its sub-processors' direct perimeter of control.

3.5. Force Majeure and Cyberattacks

  1. Force Majeure Events: Unavailability caused by events beyond the Provider's reasonable control, including but not limited to natural disasters, acts of war, terrorism, pandemics, government injunctions, or widespread telecommunications failures.

  2. Overwhelming Cyberattacks: Widespread, sophisticated Distributed Denial of Service (DDoS) attacks or targeted intrusions that bypass or overwhelm the industry-standard mitigation protections deployed by the Provider or its infrastructure partners.

    4. SERVICE CREDIT CALCULATION

4.1. The Service Credit Tiers

In the event that the Provider fails to meet the 99.5% Service Level Commitment during a specific Measurement Period (and the Downtime is not subject to any of the exclusions defined in Chapter 3), the Customer shall be eligible to receive a "Service Credit." Service Credits are calculated as a percentage of the base Monthly Subscription Fee paid by the Customer for the specific Data Plane environment that experienced the Downtime, according to the following tiered schedule:

  • 99.0% to 99.49% Uptime: 10% Service Credit
  • 95.0% to 98.99% Uptime: 25% Service Credit
  • Below 95.0% Uptime: 50% Service Credit

(Note: If the Customer is on an annual billing cycle, the Service Credit will be calculated based on 1/12th of the total annual subscription fee).

4.2. The Maximum Credit Cap

To ensure the financial stability of the Platform, the Provider's maximum total liability for all Downtime occurring within a single Measurement Period (calendar month) shall be strictly capped. Under no circumstances shall the aggregate Service Credits awarded to the Customer for a single month exceed fifty percent (50%) of the base Monthly Subscription Fee applicable to that specific month.

4.3. Nature of Credits and the Termination Exception

As a general principle, the Customer explicitly acknowledges and agrees that Service Credits are a commercial gesture designed to compensate for service degradation. The following conditions apply to all Service Credits:

  1. Future Application: Under normal operations, Service Credits will be applied exclusively as a discount against the Customer's future SaaS invoices.
  2. Standard Evaporation upon Churn: If the Customer voluntarily terminates their account for convenience, or if the Provider terminates/suspends the account due to an Acceptable Use Policy (AUP) violation, all unapplied Service Credits shall immediately evaporate and be permanently forfeited.
  3. Non-Transferable: Service Credits cannot be transferred, sold, or applied to a different Data Plane, tenant, or business entity.
  4. EXCEPTION: Termination for Cause: The "Standard Evaporation" and "Future Application" rules shall strictly not apply if the Customer terminates the master Terms of Service for cause due to a severe or chronic failure of the Provider. Specifically, if the Customer's Data Plane falls below 95.0% Uptime in a single Measurement Period, or fails to meet the 99.5% Service Level Commitment for three (3) consecutive Measurement Periods, the Customer has the right to terminate the contract for cause. In this specific scenario, any unapplied Service Credits shall be converted into a direct financial refund and disbursed to the Customer upon account closure.

5. CLAIM PROCEDURE

5.1. The Burden of Proof and Proactive Submission

The Provider’s monitoring systems evaluate the overarching health of the Shared Infrastructure, but the Provider does not automatically calculate or disburse Service Credits on an individual tenant basis. The burden of proof rests entirely on the Customer. To receive a Service Credit, the Customer must proactively submit a formal, written claim to the Provider. The claim must be submitted exclusively via the Provider’s official technical support ticketing system within the Control Plane dashboard.

5.2. The Strict Claim Deadline

To be considered valid, a Service Credit claim must be received by the Provider no later than fifteen (15) calendar days following the end of the Measurement Period (the calendar month) in which the alleged Downtime occurred. If the Customer fails to submit a formal claim within this strict 15-day window, the Customer is deemed to have irrevocably waived their right to claim any Service Credits or compensation for that specific Measurement Period.

5.3. Required Evidence

Vague reports of unavailability or slow loading times will be summarily rejected. A valid Service Credit claim must include specific, actionable technical evidence to corroborate the Downtime. The support ticket must contain, at a minimum:

  1. Exact Timestamps: The precise start and end times of the alleged Downtime, recorded in Coordinated Universal Time (UTC).
  2. Incident Description: A detailed description of the outage, including the specific Data Plane URLs affected and the exact HTTP error codes returned to the End-Consumer (e.g., HTTP 502 Bad Gateway or 503 Service Unavailable), or documentation of severe latency (TTFB) exceeding the thresholds defined in Chapter 1.
  3. Corroborating Evidence: Exported server logs, screenshots of the error state, or data reports from reputable third-party uptime monitoring services (e.g., Pingdom, Datadog, UptimeRobot) demonstrating a continuous disruption of service.

5.4. Claim Evaluation and the Source of Truth

Upon receipt of a valid claim, the Provider will evaluate the Customer's evidence against the Provider’s own internal system logs, Kubernetes health checks, and infrastructure metrics. The Parties agree to the following framework for establishing the truth of an incident:

  1. Primary Source: Under normal operating conditions, the Provider’s internal monitoring systems and logs shall serve as the primary source of truth for determining whether Downtime occurred, the duration of the Downtime, and whether any Chapter 3 Exclusions apply.
  2. Secondary Source (Fallback): The Provider acknowledges that severe infrastructure failures may occasionally incapacitate internal monitoring probes. In the event that the Provider's internal monitoring systems are rendered inoperable, inaccessible, or fail to accurately record the event due to a systemic failure, the Provider agrees to accept and evaluate in good faith the corroborating evidence provided by the Customer from reputable, industry-standard third-party monitoring services as a valid secondary source of truth.

The Provider will process all claims in good faith and will notify the Customer of the approval or rejection of the claim within thirty (30) days of receipt.

6. SOLE AND EXCLUSIVE REMEDY

6.1. The Sole Remedy Principle

The Parties explicitly acknowledge and agree that the calculation and issuance of Service Credits, as defined in Chapter 4 of this SLA, constitutes the Customer’s sole and exclusive remedy, and the Provider's entire and maximum liability, for any failure to meet the Service Level Commitment, or for any other instance of Data Plane unavailability, latency, or performance degradation.

6.2. Explicit Waiver of Indirect Damages

The Provider acknowledges that Downtime in an e-commerce environment can result in missed commercial opportunities. However, the Customer acknowledges that the Provider's SaaS pricing model is standardized and cannot absorb the infinite, unquantifiable risk of the Customer's potential sales volume. Therefore, to the maximum extent permitted by applicable law, the Customer expressly, unconditionally, and irrevocably waives any right to claim, sue for, or demand financial compensation for any indirect, incidental, special, or consequential damages resulting from Downtime. This strict waiver specifically includes, but is not limited to:

  1. Lost Revenue: Any lost sales, abandoned carts, anticipated profits, or missed commercial opportunities during the period of unavailability.
  2. Marketing Losses: Wasted digital advertising spend (e.g., Google Ads, Meta Ads, affiliate marketing) directing End-Consumers to an unavailable or degraded storefront.
  3. Reputational Harm: Loss of End-Consumer goodwill, brand damage, or any penalties incurred by the Customer due to breaches of their own third-party contracts.

6.3. Alignment with Master Terms of Service

This limitation of remedy operates in strict conjunction with the overarching Limitation of Liability provisions set forth in Chapter 10 of the master Terms of Service. In the event that a court of competent jurisdiction deems the Service Credit mechanism unenforceable or invalid for any reason, the Provider's total, aggregate financial liability for any specific outage or series of related outages shall remain strictly capped at the base Monthly Subscription Fee actually paid by the Customer for the specific Measurement Period in which the Downtime occurred.