SERVICE LEVEL AGREEMENT (SLA)

1. Definitions

“Business Hours” means 9:00am – 5:00pm Central Time (CST/CDT), Monday through Friday, excluding U.S. federal holidays. Monitoring of the Hosting Service is provided 24/7/365.

“Downtime” means any period of five (5) or more consecutive minutes during which Strategy’s monitoring platform, Uptime Robot, records a monitored service in a down state. Checks are performed at one (1) minute intervals and include HTTP/HTTPS response codes, port availability, and keyword verification of page content. Downtime is measured per site.

“Response” means a human acknowledgment from a named Strategy team member confirming receipt, the assigned priority, and the assigned owner. An automated Asana notification does not constitute a Response.

“Resolution” means the reported issue is corrected, or a workaround is in place that restores the affected business process to normal operation. Where a workaround is used, Strategy will provide a target date for permanent correction.

“Emergency Downtime” means periods where Strategy identifies a vulnerability that, based on risk assessment, requires immediate remediation, causing the Hosting Service to become temporarily unavailable. Strategy will:

  • notify you as soon as practicable and no later than two (2) hours after commencement;
  • limit the outage to the minimum time necessary; and
  • provide a written incident summary within five (5) business days.

Emergency Downtime is not counted as Downtime, except that Emergency Downtime exceeding four (4) hours in a calendar month will count as Downtime.

“Scheduled Downtime” means periods of planned unavailability for which Strategy gives you at least three (3) business days’ notice. Scheduled Downtime will be performed between 2:00am and 5:00am in the local time zone of the data center hosting your site, aligning with Kinsta’s platform maintenance period. Scheduled Downtime will not exceed three (3) hours per occurrence and will not exceed twelve (12) hours per calendar year. Scheduled Downtime is not counted as Downtime.

Strategy’s notice will state the window in your local time zone and identify the data center concerned.

“Monthly Uptime Percentage” means the total minutes in the calendar month, minus total minutes of Downtime in that month, divided by total minutes in the calendar month.

“Services” means the services provided to you by the Hosting Service, including source control, project management, ticketing, collaboration, and other services expressly agreed between you and Strategy.

“System Health Issue” means an issue affecting the stability, security, capacity, or maintainability of the hosting environment that is detected by Strategy’s monitoring rather than reported by you. Examples include backup failures, storage capacity thresholds, certificate expiry, pending security patches, and application errors preventing a function from completing.

2. Availability Commitment

Strategy will use all reasonable commercial efforts, being no less than accepted industry standards, to ensure the Hosting Service is available 99.9% of the time in any calendar month. If the Monthly Uptime Percentage falls below this, you may be eligible for a Service Credit under Section 3.

At 99.9%, the monthly allowance for Downtime is approximately 43 minutes.

3. Service Credits

One-month credit. If the Monthly Uptime Percentage for any calendar month is less than 99.9% and 95.0% or greater, you receive one (1) month of Services added to the end of your billing cycle at no charge.

Right to terminate. You may terminate the Hosting plan on seven (7) days’ written notice to Strategy if either:

  • the Monthly Uptime Percentage for any calendar month is less than 95.0%; or
  • the Monthly Uptime Percentage is less than 99.0% for three (3) consecutive calendar months.

Where the first trigger applies, you may instead elect the one-month credit described above.

Requesting a credit. You must notify Strategy in writing within 15 days of becoming eligible.

Maximum credit. Aggregate Service Credits for a single calendar month will not exceed one (1) month of Services. Credits are not exchangeable for monetary compensation.

Sole remedy. This SLA states your sole and exclusive remedy for any failure by Strategy to provide the Services as a result of Downtime.

4. Support Tickets and Change Requests

Tickets must be opened by your designated contact(s) by email to the help desk, or by phone if email is unavailable. Tickets from non-designated persons require approval by a designated contact before the SLA clock starts.

Priority assignment. You propose a priority on submission. Strategy confirms or reclassifies it within the Response window and states the reason in writing. Disputed priorities escalate to the Web Director.

4.1 Support Tickets and Change Requests

Priority Definition Example Response Status updates Resolution / workaround target Coverage
P1: Urgent Service unavailable; all users and functions affected Website is down 1 hour Hourly 4 hours 24/7/365 
P2: High Significant degradation; many users or business-critical functions affected Payment/Email is not working 2 Business hours Every 4 Business Hours 8 business hours Business Hours; best effort after hours 
P3: Medium Limited degradation; business process can continue Broken Styling 8 Business Hours Daily 16 business hours Business Hours 
P4: Low Minor degradation; limited users affected Typo 8 Business Hours Weekly 40 business hours Business Hours 
P5: Change request No effect on critical business process or uptime New copy for a site 8 Business Hours Weekly Scoped and scheduled within 40 business hours; delivery by agreement Business Hours 

Clock rules.

  • All response and resolution clocks run during Business Hours only. A P2-5 ticket submitted at 4:30pm Friday has its 1-hour Response clock expire at 9:30am Monday.
  • Clocks pause when a ticket is set to Awaiting Client pending information, access, approval, or a third-party action, and resume when you respond. Paused time is excluded from measurement.
  • Where a workaround restores normal operation, the Resolution target is met at the time the workaround is in place.

4.2 Escalation

“Escalation Time” means the elapsed time after which an unresolved ticket is automatically raised to the next tier, with notice to you:

Priority Escalation Time
P1: Urgent 2 hours
P2: High 4 Business Hours
P3: Medium 48 Business Hours
P4/P5: Low 96 Business Hours

5. System Health Issues

Strategy monitors the hosting environment 24/7/365 using Uptime Robot for availability and Sentry for application exceptions. Detected System Health Issues are acknowledged and remediated within the targets below. These are internal operating standards and do not create Service Credit entitlements.

Severity is assigned according to the functional impact of an issue. Strategy makes no commitment regarding application error rates, error volumes, or error thresholds, and no target in this SLA is measured against them.

Severity Examples Acknowledgment Remediation target Coverage 
SH1: Critical Site or service down; active security exploit; production backup failure; expired TLS certificate; an exception preventing a core function from completing (for example checkout, login, or form submission) 30 minutes 4 hours 24/7 
SH2: High Storage above 90%; single backup failure; certificate expiring within 7 days; critical-severity CVE affecting a running component; an exception preventing a non-core function from completing 4 Business Hours 8 business hours Business Hours 
SH3: Medium Storage above 80%; non-critical updates pending; certificate expiring within 30 days; sustained performance drift 8 business hours 80 business hours Business Hours 
SH4: Low Informational alerts; tuning opportunities; monitoring configuration noise 24 business hours Next scheduled maintenance window Business Hours 

Every SH1 and SH2 issue is logged as a task in Asana with detection timestamp, acknowledgment timestamp, remediation timestamp, and root cause, so that compliance is measurable rather than asserted.

6. Measurement and Reporting

Authoritative sources. Availability and Downtime timestamps are taken from Uptime Robot. Support ticket and System Health Issue timestamps are taken from Asana. Where the two disagree, Uptime Robot governs for availability and Asana governs for response and resolution.

Sentry is used for detection and diagnosis only. It is not a source of any committed metric and no SLA target is calculated from Sentry data.

7. Exclusions

The Uptime SLA does not apply to performance issues: (i) caused by factors outside Strategy’s reasonable control; (ii) resulting from your actions or inactions or those of any third party; (iii) resulting from your equipment or third-party equipment not within Strategy’s primary control; or (iv) occurring during Scheduled Downtime or Emergency Downtime within the limits of Section 1.

Underlying infrastructure provider. The hosting infrastructure is provided by Kinsta, whose service level terms are available at https://kinsta.com/legal/service-level-agreement/. Strategy’s obligations under this SLA are independent of, and not limited by, Kinsta’s terms except as stated in the Exclusions above.

Downtime occurring during Kinsta’s platform maintenance period, being daily from 2:00am to 5:00am in the local time zone of the data center hosting the site, is not counted as Downtime.

Support SLA targets do not apply where you have not provided access, information, or approvals reasonably required to progress a ticket, for the duration of that delay.

8. Client Responsibilities

To enable Strategy to meet these targets, you will:

  • maintain a current list of designated contacts;
  • provide a 24/7 contact for P1 issues;
  • respond to Awaiting Client requests within two (2) business days; and
  • submit change requests through the help desk rather than direct to individual staff.
Skip to content