Service Level Agreement
Last Updated: September 6, 2026
This Hosting & Maintenance Service Level Agreement (“SLA”) applies to website hosting and maintenance services provided by Zen Design Firm LLC, doing business as Zen Agency™, a Pennsylvania limited liability company (“Service Provider”), to its clients. In this SLA, “Client” means the Principal, as defined in the MSA, that receives hosting or maintenance Services. Together, Service Provider and Client are the “Parties.”
This SLA is part of, and is governed by, the Zen Agency™ Master Services Agreement & Terms of Service published at https://zen.agency/zen-agency-master-services-agreement-terms-of-service/ (the “MSA”). Capitalized terms not defined in this SLA have the meanings given in the MSA.
1. Acceptance, Purpose and Order of Precedence
1.1 Acceptance. Client accepts this SLA by reference when Client (a) accepts the MSA; (b) signs, electronically signs or otherwise accepts a proposal or SOW that references this SLA or the MSA; or (c) purchases, pays for or continues to use a hosting or maintenance plan. The individual accepting on behalf of Client represents that he or she has authority to bind Client.
1.2 Purpose and Plan-Specific Terms. This SLA sets out the service levels that apply to Service Provider’s hosting and maintenance Services. Plan-specific items, including server specifications, plan type, backup frequency, Troubleshooting Hours, hourly rates and fees, are stated in the Client’s plan, proposal or SOW. Where the Client’s plan, proposal or SOW is silent, the defaults in this SLA apply. Hosting service levels, including the Uptime Commitment and Service Credits, apply only to sites that Service Provider hosts. Maintenance service levels apply to sites that Service Provider maintains, wherever they are hosted.
1.3 Relationship to the MSA. For purposes of Section 18.1 of the MSA, this SLA expressly identifies and supplements Section 5 (Service Levels) of the MSA, solely for hosting and maintenance Services, by adding the severity levels, uptime measurement, Service Credits, vulnerability remediation windows, backup targets, notification commitments and reporting described below. This SLA does not modify any other section of the MSA, including Sections 2.7 (No Refunds), 6 (Warranties and Disclaimers), 7 (Indemnification), 8.5 (Malware, Cyberattacks, and Security Incidents), 8.6 (Website Accessibility), 8.8 (Maintenance and Support Plans), 8.9 (Privacy Policies, Cookie Consent, and Data Privacy Laws), 13 (Limitation of Liability), 14 (Force Majeure) and 15 (Dispute Resolution and Governing Law).
1.4 Order of Precedence. If there is any conflict, the following order applies: (a) the MSA controls, except to the extent Section 1.3 expressly supplements MSA Section 5; (b) the Client’s plan, proposal or SOW controls over this SLA, but only with respect to scope, pricing, plan specifications and timelines; and (c) this SLA controls over any proposal, SOW or invoice with respect to all other service-level terms. Purchase order or other pre-printed terms issued by Client have no effect.
1.5 Nature of Commitments. Response and resolution times in this SLA are targets, consistent with MSA Section 5. The Uptime Commitment in Section 6 is the only service level for which Service Credits are available. The remedies stated in this SLA are Client’s sole and exclusive remedies for any failure to meet a service level.
1.6 Updates. Service Provider may update this SLA from time to time by posting the updated SLA on this page with a new “Last Updated” date. Updates become effective as of the “Last Updated” date above. For any material change, Service Provider will also notify Clients with active Services by email to Client’s primary or billing contact, and the material change will apply to those Clients thirty (30) days after the email is sent. If Client does not agree to a material change, Client may terminate the affected Services by written notice under MSA Section 3.2 before the change takes effect. Continued use of the Services after an update takes effect constitutes acceptance of the updated SLA. Updates do not apply to any dispute that arose before the update took effect. Service Provider may improve a service level at any time.
2. Definitions
| Term | Meaning |
|---|---|
| Business Day | Monday through Friday, excluding United States federal holidays. |
| Business Hours | 9:00 a.m. to 5:00 p.m. Eastern Time on Business Days. |
| Covered Site | Each production website that Service Provider hosts or maintains under the Client’s plan, proposal or SOW, served from its Production Environment. |
| Ecommerce Site | A Covered Site that takes orders or payments online, such as a WooCommerce store. |
| Lead-Generation Site | A Covered Site that is not an Ecommerce Site. |
| Production Environment | The live server, web stack and WordPress installation that serve a Covered Site to the public. Staging, development and other non-production environments are not part of the Production Environment. |
| Downtime | A period during which a Covered Site is Unavailable, measured as described in Section 6.2. |
| Monthly Uptime Percentage | The total minutes in a calendar month, minus Downtime minutes not excluded under Section 6.4, divided by the total minutes in that month, expressed as a percentage. |
| Scheduled Maintenance | Maintenance announced to Client in advance as described in Section 6.3. |
| Emergency Maintenance | Unscheduled work that Service Provider reasonably determines must be performed promptly to protect the security, integrity or stability of a Covered Site or its server, including applying a critical patch or rebooting into a patched operating system kernel. |
| Incident | An unplanned interruption of, or reduction in the quality of, the Services, reported by Client or detected by Service Provider. |
| Security Incident | A confirmed unauthorized access to, or acquisition, alteration or destruction of, a Covered Site, its Production Environment or data stored on it, including malware infection, defacement, card skimming code or unauthorized administrator accounts. |
| Vulnerability | A publicly disclosed security weakness in software that Service Provider manages for a Covered Site, including the server operating system, web server, PHP, WordPress core, WooCommerce, themes and plugins. |
| Public Exploit | Working exploit code or a proof of concept that has been published, or credible reporting of active exploitation in the wild. |
| Mitigation | Action that removes or effectively blocks the attack path of a Vulnerability in the Production Environment, as described in Section 8.3. |
| Response Time | The time between Service Provider’s receipt of an Incident report through a channel in Section 4.1 (or a monitoring alert) and the first response from a member of Service Provider’s team acknowledging the Incident and beginning work. |
| Restoration Target | The target time to restore service or provide a workaround that removes the critical impact of an Incident. A permanent fix may follow later. |
| Monthly Hosting Fee | The hosting fee for a Covered Site for one month. Where hosting is billed annually, it is the annual hosting fee divided by twelve. Maintenance fees, troubleshooting time, third-party costs and other fees are not part of the Monthly Hosting Fee. |
| Service Credit | A credit calculated under Section 7 and applied against future fees. A Service Credit is not a cash payment or refund. |
| Troubleshooting Hours | The monthly allotment of troubleshooting time, if any, included in the Client’s plan, proposal or SOW. |
| RPO (Recovery Point Objective) | The maximum targeted period of data that may be lost, measured back from an Incident to the most recent usable backup. |
| RTO (Recovery Time Objective) | The targeted time to restore a Covered Site from a backup once a restore is started. |
3. Scope and Responsibilities
Responsibilities are divided among hosting, application maintenance and Client as follows, to the extent the relevant Services are included in the Client’s plan, proposal or SOW. Services not listed in this SLA or in the Client’s plan, proposal or SOW are out of scope under MSA Sections 1 and 8.8.
| Area | Service Provider: Hosting | Service Provider: Application Maintenance | Client |
|---|---|---|---|
| Infrastructure | Provision and manage the server and web stack (operating system, Nginx, PHP, database, caching) through Service Provider’s server management platform.Apply operating system and server security updates.Monitor capacity and recommend upgrades under MSA Section 8.2. | Keep PHP versions compatible with the Covered Site and plan PHP upgrades. | Select a hosting plan that fits its traffic and storage needs.Approve plan upgrades when usage exceeds plan limits. |
| Network and edge | Configure SSL certificates, CDN and Cloudflare DNS and proxy for records Service Provider manages.Operate the web application firewall, brute-force protection and server hardening. | Maintain firewall and security plugin settings at the application level. | Keep domain registration current.Keep DNS records that point to the server proxied through Cloudflare, or route DNS changes through Service Provider. |
| WordPress and WooCommerce | Provide a staging or development environment. | Update WordPress core, WooCommerce, themes and plugins on the schedule in the Client’s plan, proposal or SOW, testing in a development environment first.Review the site manually after updates and resolve conflicts caused by updates Service Provider performs, under MSA Section 8.8.Remediate Vulnerabilities under Section 8. | Not install, update or remove plugins or themes, or edit code, in production without notice to Service Provider.Own the content, products, pricing and configuration of the site. |
| Monitoring and security | Monitor uptime at one-minute intervals, 24 hours a day.Run daily security and performance scans.Contain and clean up malware under Section 10 and MSA Section 8.5. | Review vulnerability scan results and act on them under Section 8. | Use strong, unique passwords and two-factor authentication, and limit administrator access to authorized users (MSA Section 8.3).Report suspected Security Incidents promptly. |
| Backups and recovery | Run local and external backups under Section 9.Restore from backup when needed under Section 9. | Verify the Covered Site after a restore. | Reconcile orders and other transactions made after the restored backup, using payment gateway and other system records. |
| Third-party services | Coordinate with upstream providers during outages. | Maintain plugin licenses that Service Provider supplies while the plan is active. | Maintain its own accounts and contracts with payment gateways, shipping, tax, email, marketing and other third-party services, and its PCI DSS compliance (MSA Section 8.5(c)). |
4. Support Channels, Hours and Escalation
4.1 Channels. Client reports Incidents and requests by ticket or email to [email protected], or by phone at 1.800.775.9610. P1 Incidents should be reported by phone and email. Response Times are measured from the earlier of Service Provider’s receipt of a report through one of these channels or a monitoring alert.
4.2 Hours. Automated uptime and security monitoring runs 24 hours a day, 7 days a week. Support staff respond during Business Hours. Outside Business Hours, Service Provider will use commercially reasonable efforts to respond to P1 Incidents but no Response Time or Restoration Target applies, and the clock for each target begins at the start of the next Business Hours period.
4.3 Escalation. If a P1 or P2 Incident is not progressing, Client may escalate first to its account manager and then to Zen leadership, through the channels in Section 4.1.
4.4 Billable Time. Time spent on Incidents caused by Service Provider’s hosting infrastructure or by updates Service Provider performed is not charged. Other troubleshooting and support time draws from Client’s Troubleshooting Hours, if any, and time beyond them is billed at the hourly rate stated in the Client’s plan, proposal or SOW or, if none is stated, at the rate in MSA Section 2.3. Unused Troubleshooting Hours are subject to MSA Section 2.7.
5. Severity Levels, Response and Restoration Targets
5.1 Classification. Service Provider assigns a severity level to each Incident based on its business impact, using the definitions below, and may reclassify an Incident as more information becomes available. Client may request a different classification, and Service Provider will consider it in good faith.
| Severity | Definition and examples | Response Time (Business Hours) | Restoration Target | Status updates |
|---|---|---|---|---|
| P1 – Critical | A Covered Site is down or checkout cannot be completed for all customers, or a Security Incident is active.Examples: site returns errors to all visitors; cart or checkout fails for all orders; malware or skimming code detected. | 1 hour | Restore service or provide a workaround within 4 Business Hours after response | Every 2 Business Hours until restored |
| P2 – High | A major function is degraded, with no reasonable workaround, while the site remains online.Examples: one payment method failing; WordPress administration unavailable; severe slowdowns; order or form emails not sending. | 4 Business Hours | 1 Business Day after response | Once per Business Day |
| P3 – Medium | A non-critical function is impaired, or a workaround exists.Examples: a plugin feature or form not working; layout issue on some pages. | 1 Business Day | 5 Business Days after response | On resolution or as agreed |
| P4 – Low | Cosmetic issues, questions and routine requests.Examples: minor styling issue; how-to question; small configuration change. | 1 Business Day | Next monthly maintenance cycle, or as scheduled with Client | On resolution |
5.2 Targets. Response Times and Restoration Targets are targets, not guarantees, consistent with MSA Section 5. Missing a target is not a breach of this SLA and does not create a right to Service Credits. Client’s remedy is escalation under Section 4.3 and, on request, a written explanation in the next monthly report.
5.3 Pauses and Out-of-Scope Requests. Targets are paused while Service Provider is waiting on Client or a third party for access, information, approval or action, and while an exclusion in Section 6.4 applies. Requests for new features, design changes, content changes or other work outside the plan are not Incidents and are scheduled as billable work.
6. Availability
6.1 Uptime Commitment. For each Covered Site that Service Provider hosts, Service Provider will provide a Monthly Uptime Percentage of at least 99.9%, excluding Scheduled Maintenance and the other exclusions in Section 6.4 (the “Uptime Commitment”). A 99.9% monthly uptime allows approximately 43 minutes of Downtime in a 30-day month.
6.2 Measurement. Service Provider’s monitoring checks the home page of each hosted Covered Site over HTTPS every minute. A check fails if the page does not respond within 30 seconds or returns an HTTP 5xx status, including Cloudflare status codes that show the origin server could not be reached (such as 521, 522, 523 and 524). A Covered Site is Unavailable from the first of two or more consecutive failed checks until the next successful check. Service Provider’s monitoring records are the measurement of record. If Client reports an outage that the monitoring did not record, Service Provider will review Client’s evidence in good faith.
6.3 Scheduled and Emergency Maintenance. Service Provider will give Client at least 48 hours’ notice by email of Scheduled Maintenance that is expected to cause Downtime, and will schedule it outside Business Hours where practicable and at times of lower site traffic. Scheduled Maintenance is excluded from Downtime up to 4 hours per calendar month. Scheduled Maintenance beyond 4 hours in a month counts as Downtime. Emergency Maintenance is excluded from Downtime, and Service Provider will notify Client as soon as practicable, before the work where possible.
6.4 Exclusions. Downtime does not include Unavailability caused by any of the following:
- Scheduled Maintenance within the monthly limit in Section 6.3, and Emergency Maintenance.
- Changes, code, content, plugins, themes or settings made by Client or anyone acting for Client other than Service Provider, or Client’s failure to follow Service Provider’s reasonable instructions or security recommendations.
- Third-party services, including payment gateways, shipping, tax and email services, external APIs and scripts, licensing servers and plugin vendors.
- Outages or degradation of Cloudflare, the upstream infrastructure or data center provider, the server management platform, DNS providers, domain registrars or internet carriers.
- Distributed denial-of-service attacks or other attack traffic that exceeds what the firewall and Cloudflare protections in place can reasonably absorb, and traffic beyond the resource limits of the hosting plan (MSA Section 8.2).
- Suspension of the Services for non-payment or chargebacks under MSA Sections 2.5 and 2.8, or at Client’s request.
- Force majeure events under MSA Section 14.
- Problems in non-production environments, or issues affecting only individual users, devices, browsers, networks or geographic locations.
- Steps Service Provider takes to contain a Security Incident under Section 10, such as placing a Covered Site in maintenance mode, unless the Security Incident was caused by Service Provider’s failure to perform this SLA.
7. Service Credits
7.1 Credit Schedule. If the Monthly Uptime Percentage for a hosted Covered Site falls below the Uptime Commitment in a calendar month, Client is eligible for the following Service Credit, calculated as a percentage of the Monthly Hosting Fee for that Covered Site for that month:
| Monthly Uptime Percentage | Service Credit (% of Monthly Hosting Fee) |
|---|---|
| 99.9% or higher | None |
| Below 99.9% and at least 99.5% | 5% |
| Below 99.5% and at least 99.0% | 10% |
| Below 99.0% and at least 98.0% | 15% |
| Below 98.0% | 25% |
7.2 Cap. Total Service Credits for any Covered Site for any calendar month will not exceed 25% of the Monthly Hosting Fee for that month. Service Credits apply only to the Monthly Hosting Fee and not to maintenance fees, troubleshooting time, third-party costs or any other fees.
7.3 Request Procedure. To receive a Service Credit, Client must submit a written request to [email protected] within 30 days after the end of the month in which the Downtime occurred, identifying the Covered Site and the dates and approximate times of the Downtime. Service Provider will verify the request against its monitoring records and respond within 10 Business Days. Requests not made within 30 days are waived.
7.4 Application. Approved Service Credits are applied to Client’s next invoice for Services. Service Credits have no cash value, are not refunds under MSA Section 2.7, cannot be transferred, and are forfeited if not used when the Services end. Service Credits are not available for any month in which Client’s account is past due.
7.5 Sole Remedy. Service Credits are Client’s sole and exclusive remedy for any failure to meet the Uptime Commitment. Service Credits count toward, and do not increase, the limitation of liability in MSA Section 13.
8. Vulnerability Management
8.1 Monitoring. Service Provider monitors vendor security advisories, public vulnerability databases, operating system security notices and the results of its daily security scans for Vulnerabilities affecting Covered Sites and their Production Environments.
8.2 Severity. Service Provider assigns severity using the CVSS v3.1 (or later) base score published by the software vendor or the National Vulnerability Database, and may raise the severity of a Vulnerability where Service Provider reasonably determines that it is more readily exploitable in the Production Environment. A Critical Vulnerability without a Public Exploit is treated as High.
| Severity | Mitigation window |
|---|---|
| Critical (CVSS 9.0–10.0) with a Public Exploit | Target within 24 hours, and no later than 72 hours, after a vendor patch or published mitigation becomes available |
| High (CVSS 7.0–8.9), and Critical without a Public Exploit | Within 7 calendar days after a vendor patch or published mitigation becomes available |
| Medium (CVSS 4.0–6.9) and Low (CVSS 0.1–3.9) | In the next monthly maintenance cycle after a vendor patch becomes available |
8.3 What Counts as Mitigation. A Vulnerability is mitigated when Service Provider has done one or more of the following in the Production Environment: (a) applied the vendor’s patch or updated to a fixed version; (b) deployed a virtual patch through the web application firewall or Cloudflare that blocks the known attack path; (c) disabled, removed or replaced the affected component; or (d) applied a configuration or operating system change published by the vendor or a recognized security source. A virtual patch or other interim Mitigation counts only where it is effective at the layer where the Vulnerability exists. Where an interim Mitigation is used, Service Provider will apply the permanent fix within the window for the Vulnerability’s severity or, if no permanent fix is yet available, within the same window after it becomes available.
8.4 Emergency Patching. For Critical and High Vulnerabilities, Service Provider may apply a patch directly to the Production Environment after taking a fresh backup and performing abbreviated testing, rather than waiting for the full development-environment testing used in the monthly cycle. A patch that requires a server reboot is performed as Emergency Maintenance. Client acknowledges that updates can cause conflicts, as described in MSA Section 8.8, and Service Provider will resolve conflicts caused by its updates under that section.
8.5 No Patch Available; Exceptions. Where no vendor patch or published mitigation exists, including zero-day Vulnerabilities, Service Provider will apply commercially reasonable compensating controls, and the mitigation window starts when a patch or published mitigation becomes available. Where a plugin or theme is abandoned or its vendor does not release a fix, Service Provider will notify Client and recommend a replacement; replacement and related rework are billable unless included in the Client’s plan, proposal or SOW. Components that Client installed or controls, and custom code not maintained by Service Provider, are excluded from the windows in this Section. Where Service Provider maintains but does not host a Covered Site, the windows apply to the WordPress application only, and server-level Vulnerabilities remain the responsibility of the hosting provider.
8.6 Communication. Service Provider will notify Client by email within one Business Day after mitigating a Critical Vulnerability that affected a Covered Site, and will list each Vulnerability addressed, with its severity and mitigation date, in the monthly report.
8.7 Remedy. If Service Provider misses a mitigation window, Service Provider will complete the Mitigation at no additional charge and provide Client a written explanation. This Section does not modify MSA Section 8.5, including Section 8.5(b) (Third-Party Vulnerabilities), and creates no liability beyond MSA Section 13.
9. Backups, RPO and RTO
9.1 Backup Schedule. Service Provider runs two layers of automated backups of the WordPress files and database for each Covered Site. Unless the Client’s plan, proposal or SOW states otherwise:
- Local backups on the server run hourly for Ecommerce Sites and daily for Lead-Generation Sites.
- External backups run daily for all Covered Sites, through a third-party backup service that stores copies off the server.
9.2 Retention and Monitoring. Backups are retained for the retention period configured in the backup systems in use. Service Provider will confirm the current retention periods to Client on request and in the monthly report. The server pauses local backups if available disk space falls below a safety threshold; Service Provider monitors backup status and will resolve a paused or failed backup as a P2 Incident.
9.3 Restore Testing. At least once each calendar quarter, Service Provider will restore a recent backup of each Covered Site to a non-production environment to confirm that it can be restored, and will report the result in the monthly report.
| Measure | Ecommerce Sites | Lead-Generation Sites |
|---|---|---|
| RPO when restoring from a local backup | 1 hour | 24 hours |
| RPO when restoring from an external backup | 24 hours | 24 hours |
| Start of restore after Service Provider decides a restore is required | Within the P1 Response Time | Within the P1 Response Time |
| RTO from a local backup | 4 Business Hours after the restore starts | 4 Business Hours after the restore starts |
| RTO from an external backup | 1 Business Day after the restore starts | 1 Business Day after the restore starts |
9.4 Limits. The RPO and RTO above assume the default backup schedule in Section 9.1. If the Client’s plan, proposal or SOW sets a different schedule, the RPO equals the interval of the backup used. RPO and RTO are targets. Orders, customer accounts, form entries and other data created after the backup used for a restore may be lost and must be re-entered or reconciled by Client from payment gateway and other records. Backups do not include data held by third-party services, email mailboxes, payment gateway records or Cloudflare settings. Restores required because of Client’s actions draw from Troubleshooting Hours or are billed under Section 4.4, and restores required because of a hosting failure or an update performed by Service Provider are not charged. Damages for lost data are governed by MSA Section 13.
10. Security Incidents and Breach Notification
10.1 Response. Security Incidents are handled as P1 Incidents. Service Provider may take immediate containment steps, including placing a Covered Site in maintenance mode, blocking traffic, disabling compromised accounts or components, rotating credentials and restoring from a clean backup.
10.2 Notification. Service Provider will notify Client’s primary contact by email and phone without undue delay, and no later than 24 hours, after confirming a Security Incident affecting a Covered Site or data stored on it. The notice will describe what is known at that time, including the nature of the incident, the systems and data that appear to be affected, the containment steps taken and recommended actions for Client. Service Provider will provide updates at the P1 cadence until the incident is contained.
10.3 Incident Summary and Records. Within 5 Business Days after containment, Service Provider will provide a written incident summary describing the cause where known, the timeline, the data and systems affected, the remediation performed and recommended preventive measures. Service Provider will preserve the logs available to it for the period of the incident and share relevant logs with Client on request.
10.4 Responsibilities and Liability. Malware cleanup, where included in the Client’s plan, proposal or SOW, is provided on a commercially reasonable, best-efforts basis under MSA Section 8.5. Client is responsible for notifications to customers, regulators, card brands and payment processors required by law or contract, for PCI DSS obligations, and for the cost of any third-party forensic investigation it requests. Liability for Security Incidents is governed by MSA Sections 8.5(f) and 13.
11. Client Obligations
Client’s obligations under the MSA and the Client’s plan, proposal or SOW apply. In addition, to receive the service levels in this SLA, Client will:
- Name a primary contact and a backup contact who can make decisions during an Incident, with current email and phone details, and keep them up to date.
- Provide and maintain the access Service Provider needs, including domain, DNS, Cloudflare and third-party service access (MSA Section 8.1).
- Use strong, unique passwords and two-factor authentication, limit administrator accounts to authorized users, and remove access for people who no longer need it (MSA Section 8.3).
- Give Service Provider advance notice before installing, updating or removing plugins or themes, changing code, or giving other developers access to the Production Environment.
- Route DNS changes for records that point to the server through Service Provider, and keep those records proxied through Cloudflare.
- Maintain its own accounts with payment gateways and other third-party services, keep its PCI DSS compliance current where it accepts payments, and promptly report suspected fraud or Security Incidents.
- Respond promptly to requests for information, approvals and testing, including approval of plan upgrades and replacement of unsupported components.
- Keep its account current. Service may be suspended for non-payment under MSA Section 2.5.
- Remain responsible for website accessibility, privacy policies, cookie consent and legal compliance under MSA Sections 8.6 and 8.9. Service Provider does not guarantee compliance with the Americans with Disabilities Act, WCAG or any other accessibility standard, including where Client uses third-party accessibility or privacy tools offered through Service Provider.
Delays or failures caused by Client may extend timelines, affect feasibility or increase costs, and do not create any right to Service Credits, refunds or fee reductions.
12. Reporting
Where the Client’s plan, proposal or SOW includes a monthly report, Service Provider will deliver it within 10 Business Days after the end of each month. The report will include, as applicable to the plan:
- The Monthly Uptime Percentage, each Downtime event with its duration and cause, and any Scheduled or Emergency Maintenance performed.
- The number of core, theme and plugin updates, with the date of each update and the old and new version numbers.
- Vulnerabilities identified and mitigated, with their severity and mitigation dates, and any open items with their planned dates.
- Security activity, including attacks blocked, brute-force attacks blocked and attacker IP addresses blocked.
- Backup status, retention periods and the results of any restore test.
- P1 and P2 Incidents, with Response Times and restoration times, and Troubleshooting Hours used.
- Posts, pages and products added; form starts, submissions and conversion rate; and revenue, sales, orders placed and items purchased, where the site’s data allows.
13. General Limitations
Except as expressly stated in this SLA, the Services are provided under the warranties, disclaimers and limitations of the MSA. Nothing in this SLA guarantees that a Covered Site will be free of errors, interruptions, malware or Security Incidents (MSA Section 8.5), or that it will comply with any accessibility standard (MSA Section 8.6). All amounts and remedies under this SLA, including Service Credits, are subject to the limitation of liability in MSA Section 13, which caps Service Provider’s aggregate liability at the fees actually paid by Client in the three months immediately preceding the event giving rise to the claim and excludes indirect and consequential damages, including lost revenue and lost data.
14. Term, Termination, Notices and Governing Law
14.1 Term. This SLA applies to each Covered Site for as long as Service Provider provides hosting or maintenance Services for it, including renewals.
14.2 Termination. Either Party may terminate the Services under MSA Section 3.2 on 30 days’ written notice. Termination does not create a right to a refund (MSA Section 2.7). Unused Service Credits are forfeited when the Services end. Migration assistance on termination is billed under MSA Section 3.4.
14.3 Notices and Governing Law. Notices under this SLA are given as described in MSA Section 18.4. Disputes are resolved under MSA Section 15, and this SLA is governed by the laws of the Commonwealth of Pennsylvania.
