Service Level Agreement (SLA)

1) Overview

This Service Level Agreement (“SLA”) applies to Tofido’s hosting and managed services (“Services”) and describes our uptime targets, support responsiveness, maintenance practices, incident management, and service credits. This SLA is part of the agreement between you and Tofido and is subject to the Terms of Service and any applicable statements of work or order forms.

Contact for support and SLA matters: [email protected]

2) Definitions

  • Uptime: The percentage of total time in a calendar month during which the production service is available and responding as designed, excluding Exclusions (Section 9).
  • Downtime: Any full outage window where production service is unavailable due to causes within Tofido’s reasonable control, measured by our monitoring.
  • Business Hours: [e.g., 9:00–18:00 IST, Mon–Fri, excluding public holidays].
  • 24×7: Around‑the‑clock coverage for critical incidents, if included in your plan.
  • Incident Priority (P1–P4): Severity classification defined in Section 5.

3) Uptime Commitment

PlanMonthly Uptime TargetScope
Standard99.5%Single-region hosting with shared resources and standard redundancy.
Professional99.9%Enhanced redundancy (e.g., multi‑AZ), CDN, and proactive scaling policies.
Advanced/HA99.95%High‑availability topology (e.g., multi‑AZ or multi‑node), health checks, failover.

Actual achievable uptime depends on architecture selected by you and specified in your engagement documents. Availability of third‑party dependencies (e.g., upstream cloud, DNS, payment gateways) may impact results (see Exclusions).

4) Monitoring & Measurement

  • Tofido monitors key endpoints using external synthetic checks and internal health probes.
  • Uptime is measured monthly in whole minutes and excludes scheduled maintenance and Exclusions.
  • Status updates may be provided via email or status page (if applicable to your plan).

5) Incident Priority, Response & Restoration Targets

PriorityDescriptionInitial ResponseWork StartTarget Restoration/MitigationCoverage
P1 – CriticalTotal outage, data loss in progress, severe security incident, payments down in production.15 min (24×7)Immediate (24×7)2 hours to mitigate/restore service to partial or full operation24×7 (if plan includes 24×7); otherwise best effort outside Business Hours
P2 – HighMajor functionality degraded; workarounds exist; significant performance issues.1 hour (Business Hours)2 hours8 business hours to mitigate/restoreBusiness Hours (after‑hours best effort if plan includes)
P3 – MediumMinor issues, intermittent errors, routine bugs with workarounds.1 business day2 business daysWithin planned sprint/maintenance cycleBusiness Hours
P4 – LowEnhancements, cosmetic changes, informational requests.2 business daysAs scheduledAs scheduledBusiness Hours

Targets are goals, not guarantees, and may vary by plan and architecture. For security incidents, communications may be limited while containment is in progress.

6) Maintenance Windows

  • Planned maintenance: Usually scheduled during low‑traffic hours [e.g., Sat/Sun 00:00–04:00 local region]. Notice is provided at least 48 hours in advance when service impact is expected.
  • Emergency maintenance: May occur at any time to address critical security or stability issues. We will provide notice when feasible.
  • Planned maintenance windows do not count as Downtime.

7) Backups & Recovery

  • Application/database backups: [e.g., daily snapshots retained for 7–30 days, depending on plan].
  • Restores: Best‑effort restore times vary by data size and platform; typical initiation within [2–4] hours for P1 incidents, subject to infrastructure constraints.
  • Disaster recovery options and RPO/RTO targets can be defined in your architecture plan (Advanced/HA plans recommended for strict RPO/RTO).

8) Security & Patch Management

  • Critical security patches applied as soon as practicable, often within [24–72] hours of availability, with emergency windows if needed.
  • Routine updates are deployed during planned maintenance windows.
  • Security responsibilities are shared; you must keep application code, plugins, and third‑party integrations maintained per guidance.

9) Exclusions (Not Counted as Downtime)

  • Issues caused by your acts or omissions (e.g., code changes, misconfigurations, third‑party themes/plugins, exceeding plan limits).
  • Third‑party provider outages (cloud/IaaS, registrars, DNS, CDNs, payment gateways, email/SMS providers) beyond Tofido’s reasonable control.
  • DDoS or other attacks that exceed provisioned mitigation capacity, or force majeure events (e.g., natural disasters, internet backbone failures, war, government actions).
  • Planned or emergency maintenance as described in Section 6.
  • Beta features or sandbox/staging/non‑production environments.
  • Failing to implement recommended redundancy (e.g., single‑AZ single‑node architecture on a high‑traffic workload).
  • Customer network/connectivity issues or client‑side errors.

10) Service Credits

If monthly Uptime falls below the target for your plan (Section 3), you may be eligible for a service credit as outlined below:

Measured Monthly UptimeCredit (% of Monthly Recurring Fee for the affected service)
< Target by up to 0.5%5%
Target − 0.51% to Target − 1.0%10%
Target − 1.01% to Target − 2.0%20%
More than 2.0% below Target30%
  • Credits apply only to the monthly recurring fee for the affected service component (not to usage overages, project fees, or third‑party charges).
  • Credits are not refunds and have no cash value; they are applied to future invoices for that service.
  • Total credits in a month will not exceed 50% of the monthly recurring fee for the affected service.

11) Requesting a Credit

  • Send your request within 30 days after the month in which the incident occurred to [email protected].
  • Include: account/tenant ID, affected service, incident dates/times (with timezone), observed impact, and relevant logs/screenshots if available.
  • Tofido will review monitoring data and respond within 15 business days.

12) Customer Responsibilities

  • Follow deployment and change‑management guidance; use staging for testing; coordinate high‑risk releases.
  • Maintain application dependencies, CMS/plugins, and licenses; remove vulnerable components promptly.
  • Keep credentials secure; implement MFA and least‑privilege access; update contact and escalation details.
  • Respect plan limits and architect for load (e.g., caching, CDN, queues) as recommended.

13) Escalation & Communication

  • Primary channel: [email protected] (ticket creation/triage).
  • For P1 incidents, we will provide periodic updates until mitigation (channel may include email or status page, depending on plan).
  • Post‑incident reviews may be provided upon request for P1/P2 incidents.

14) Plan‑Specific Add‑Ons (Optional)

  • 24×7 On‑Call: Guaranteed after‑hours response for P1/P2 incidents.
  • Enhanced DR: Defined RPO/RTO targets with documented failover tests.
  • Advanced WAF/CDN: Layer‑7 protection and tuning.
  • Performance SLOs: Page‑speed or API latency targets with optimization support.

15) Changes to this SLA

We may update this SLA to reflect changes in infrastructure, vendors, or best practices. We will revise the “Last updated” date and provide additional notice if changes are material. Continued use of the Services after updated terms take effect constitutes acceptance.

16) Order of Precedence & Governing Terms

If there is a conflict between this SLA and your signed engagement documents, the engagement documents govern for that service. This SLA is governed by the same law and dispute resolution terms as the Terms of Service.

Appendix – Example Architecture Notes (Fill Per Client)

  • Region(s): [e.g., ap-south-1 (Mumbai), eu-central-1 (Frankfurt)]
  • Topology: [Single‑AZ/ Multi‑AZ, autoscaling policy, DB replication, cache tier]
  • CDN/WAF: [Enabled/Disabled; provider]
  • Backups: [Frequency/Retention, e.g., daily, 14 days]
  • Monitoring: [Synthetic checks, APM, log aggregation]
  • Support Coverage: [Business Hours only / 24×7 P1/P2]