SLA

Service Level Agreement

This Service Level Agreement summarizes availability, incident response, and support targets for managed hosting and related operational services.

Last updated: March 18, 2026

UPTIME TARGET

99.95%

Monthly service availability target for covered services, not a strict guarantee, and always subject to exclusions.

P1 RESPONSE

15 Minutes

Target initial acknowledgment for critical incidents that cause full outage or major production impact.

SUPPORT WINDOW

24/7 Monitoring

Operational monitoring is continuous; response and escalation procedures vary by service tier and contract.

1. Incident Severity Model

  • P1: Full outage or critical security event affecting production availability.
  • P2: Major degradation with significant business impact and no immediate workaround.
  • P3: Partial issue with workaround available and moderate operational impact.
  • P4: Informational requests, low-risk defects, or planned improvements.

2. Service Credits And Exclusions

  • Any SLA service credit, where contractually available, is the sole and exclusive remedy for availability-related claims.
  • Exclusions include customer misconfiguration, third-party failures, registrar incidents, upstream network incidents, DDoS and cyberattacks, and force majeure.
  • Credit claims must be submitted within the claim window defined in signed contracts.
  • No guaranteed repair, restoration, or recovery timeline is provided unless explicitly committed in a signed enterprise addendum.
  • This public SLA is informational and may be superseded by negotiated enterprise contracts.

How SLA expectations should be applied in planning

An SLA is most useful when operational teams map response expectations before incidents occur. For business-critical services, define who escalates alerts, who approves mitigation decisions, and how status updates are communicated to stakeholders. This reduces downtime impact and avoids delays during active incidents.

Availability targets and response objectives must be read with exclusions and contract scope in mind. Different service layers can involve infrastructure providers, registrar dependencies, or third-party integrations. Planning for these dependencies helps teams set realistic recovery assumptions and continuity controls.

  • Map incident ownership and escalation paths in advance.
  • Align response targets with actual service tier coverage.
  • Document dependencies that may affect restoration timelines.
  • Review post-incident lessons to improve resilience over time.

FAQ

SLA FAQ

Is the uptime target a strict guarantee?

No. It is a target for covered services and remains subject to exclusions and contract scope.

How should teams use SLA targets in operations?

Map escalation ownership and incident communication before critical events happen.

Include dependency awareness for registrar, network, and third-party components. A practical incident plan based on SLA targets helps teams act faster and communicate clearly during high-impact outages.

What should be documented after a critical incident?

Document timeline, root cause, mitigation actions, and customer communication outcomes.

A post-incident record supports accountability and helps teams improve alerting, escalation, and recovery procedures. This strengthens operational resilience and aligns future response with SLA expectations.