Service Level Agreement

Last Updated: June 10, 2026

This Service Level Agreement ("SLA") describes the service commitments for Tergum's high-availability failover service (the "Service"). This SLA forms part of and is incorporated into the Terms of Service. Capitalized terms not defined herein have the meanings given in the Terms of Service.

1. Tergum Platform Availability

1.1 Uptime Commitment

We commit to maintaining 99.9% uptime for the Tergum platform each calendar month, which includes:

• The dashboard accessible at app.tergum.ca
• The API that receives Agent heartbeats and health check data
• The monitoring and alerting systems that detect outages
• The failover orchestration system that triggers DNS changes

99.9% monthly uptime equates to no more than approximately 43.2 minutes of unplanned downtime per month, or 8.76 hours per year.

1.2 Measurement Method

Platform uptime is measured using automated monitoring that checks platform availability every 60 seconds. Monthly Uptime Percentage is calculated as follows:

Monthly Uptime % = ((Total Minutes in Calendar Month − Downtime Minutes) ÷ Total Minutes in Calendar Month) × 100

Where Total Minutes in Calendar Month is the exact number of minutes in the relevant month (40,320 for February in a non-leap year; 41,760 for February in a leap year; 43,200 for 30-day months; 44,640 for 31-day months), and Downtime Minutesis the total minutes of unavailability as recorded by our monitoring system, excluding:

• Scheduled maintenance windows (see Section 7)
• Exclusions listed in Section 1.3
• Partial degradation where core failover functionality remains operational

1.3 Exclusions from Uptime Commitment

The uptime commitment does NOT apply to downtime caused by:

• Scheduled maintenance announced at least 48 hours in advance via email
• Emergency security maintenance (which we will announce as soon as reasonably possible)
• Force majeure events as defined in the Terms of Service, including natural disasters, pandemics, war, terrorism, government actions, and failures of critical infrastructure providers (AWS, Google Cloud, Azure)
• Issues originating from your servers, network infrastructure, or internet service provider
• Failures of third-party services beyond our control, including Cloudflare, Tailscale, Stripe, or DNS providers
• DNS propagation delays beyond our control (TTL caching varies by ISP and location)
• Your misconfiguration, unauthorized modifications to the Agent software, or failure to follow our documentation
• Denial of service attacks, security incidents, or other malicious activities directed at the Service
• Your use of the Service in violation of the Terms of Service or Acceptable Use Policy
• Beta, experimental, or preview features clearly marked as such

2. Failover Performance

2.1 Outage Detection Time

The Service agent sends a heartbeat to the platform every 30 seconds. When your primary server becomes unreachable, outage detection time depends on your configured failover policy:

• Conservative (default): 60–90 seconds. Requires both the agent heartbeat to go missing for 60 seconds AND 2 consecutive HTTP health check failures before triggering failover. Maximum 10 seconds replication lag. Recommended for most sites.
• Tolerant: 90–120 seconds. Triggers on agent heartbeat failure alone (no HTTP check required) after a 90-second timeout. Accepts up to 5 minutes of replication lag. For sites that can tolerate brief data inconsistency in exchange for faster automated response.
• Strict: 30–60 seconds. Requires both heartbeat failure (30-second timeout) AND 1 consecutive HTTP health check failure. Maximum 5 seconds replication lag. For low-latency, data-integrity-sensitive deployments.
• Manual: No automatic failover. The Service monitors and alerts normally, but failover is only triggered when you initiate it from the dashboard.

Detection times are measured from the moment of actual failure to when the platform confirms the outage. Actual elapsed time may vary based on network conditions and heartbeat arrival timing. The dual-signal requirement (heartbeat + HTTP) used by Conservative and Strict policies reduces false positives from transient network issues.

2.2 Failover Execution Time

Once an outage is confirmed, the Service initiates automated failover. A typical failover consists of:

• Verification that the standby server is healthy and ready (5-10 seconds)
• DNS record update via Cloudflare API to point traffic to the standby server (10-30 seconds)
• Email notification sent to configured addresses (5-15 seconds)
• Dashboard status update (immediate)

Target failover completion time: Within 5 minutes from confirmed outage detection to DNS update.

Note that DNS propagation time (the time it takes for visitors' devices and ISPs to recognize the DNS change) varies and is outside our control. Most visitors will see the change within 1-5 minutes due to low TTL settings, but some may experience longer delays based on their ISP's caching behavior.

2.3 Failover Success Rate Target

We target a 95% success rate for failover attempts, meaning that when the Service detects an outage and the standby server is healthy, failover should complete successfully 95% of the time. Failures to meet this target do not count as platform downtime for purposes of Section 1.1 but may qualify for service credits under Section 6 if they substantially impair the Service.

2.4 What Failover Cannot Guarantee

The Service cannot guarantee:

• Zero data loss - replication may have lag at the time of failure
• Instantaneous DNS propagation - visitor caching and ISP behavior varies
• Detection of application-level issues that do not affect health checks (e.g., database corruption, plugin bugs, PHP errors)
• Recovery from simultaneous failure of both primary and standby servers
• Functionality of features that depend on primary-specific configurations or local files not synchronized
• Perfect replication synchronization - some lag is normal and expected

3. Data Replication

3.1 Replication Performance Targets

Under normal operating conditions with adequate network bandwidth and server resources:

• Database replication lag: Target of under 10 seconds for typical workloads
• File synchronization: Changes detected and synced within 30 seconds

Actual replication lag depends on multiple factors outside our control:

• Network bandwidth and latency between your servers
• Server CPU, memory, and disk I/O performance
• Volume of database writes and file changes
• Size and complexity of database transactions
• Presence of long-running database queries or table locks

High-traffic sites with frequent database writes may experience higher replication lag. This is normal and expected behavior.

3.2 Replication Monitoring and Alerts

The dashboard displays real-time replication status, including current lag time and last sync timestamp. We send alerts when:

• Replication lag exceeds your configured threshold (default: 30 seconds)
• Replication stops entirely or encounters errors
• File synchronization service stops running or fails repeatedly
• Standby server database becomes disconnected

3.3 Data Loss Disclaimer

IMPORTANT: While we target minimal replication lag, some data loss may occur during failover events due to replication lag at the time of failure. We are not liable for data loss resulting from replication lag or failover events. The Service is not a backup solution. You must maintain independent, regular backups as the primary protection against data loss.

4. Support Response Times

We provide technical support via email at [email protected]. Response times are measured from when we receive your support request to when we provide an initial substantive response (not including automated acknowledgments).

Business Hours: Monday-Friday, 9:00 AM - 5:00 PM Pacific Time, excluding Canadian statutory holidays.

After Hours: For Critical issues only, we provide best-effort monitoring and response outside business hours. Response times shown are targets; actual response may vary based on issue complexity and staff availability.

Response times begin when your request is received during business hours. For requests received outside business hours, the clock starts at the beginning of the next business day, except for Critical issues which receive best-effort after-hours response.

5. Customer Responsibilities

To receive the benefits of this SLA and for the Service to function properly, you must:

• Maintain both primary and standby servers in operational condition with adequate resources (CPU, memory, disk space, bandwidth)
• Ensure both servers meet our published system requirements and compatibility standards
• Keep Tergum Agent software running and able to communicate with our platform
• Keep servers updated with critical security patches and maintain compatible software versions
• Maintain valid, working Cloudflare API credentials with appropriate permissions for DNS management
• Configure appropriate failover policies for your specific use case and tolerance for false positives
• Monitor alerts and respond promptly to notifications about server issues, replication problems, or configuration errors
• Maintain independent, regular backups (daily or more frequent) - the Service is not a backup solution
• Maintain reliable network connectivity between your servers and between your servers and our platform
• Not modify, tamper with, or reverse engineer the Agent software
• Provide accurate contact information for alerts and notifications

Failure to meet these responsibilities may affect our ability to meet the SLA commitments and may void eligibility for service credits.

6. Service Credits

6.1 Eligibility

If we fail to meet the 99.9% platform uptime commitment in Section 1.1 for any calendar month, we may, at our sole discretion, issue service credits upon request. The following schedule describes the maximum credit available in each scenario:

• 99.0% - 99.9% uptime: Up to 10% credit of that month’s subscription fee
• 95.0% - 99.0% uptime: Up to 25% credit of that month’s subscription fee
• Below 95.0% uptime: Up to 100% credit of that month’s subscription fee

For example: If you pay $100/month and we achieve 98.5% uptime in a month, you may receive a credit of up to $25, issued at our discretion upon a valid request.

6.2 Credit Limitations and Conditions

• Service credits are applied to future monthly invoices and cannot be redeemed for cash
• Maximum credit per calendar month is 100% of that month's subscription fee
• Credits must be requested within 60 days of the end of the calendar month in which the incident occurred
• Credits do not apply to downtime caused by exclusions listed in Section 1.3
• Credits are not available if you have failed to meet your responsibilities under Section 5
• Credits are available only to customers with paid subscriptions in good standing (no outstanding payment issues)
• Credits expire 12 months after issuance if not used

6.3 Remedy Limitations

Service credits issued under this Section 6 are your sole and exclusive remedy for platform uptime failures under this SLA. The issuance of credits is at Tergum’s sole discretion and is contingent on a valid request meeting the conditions in Sections 6.2 and 6.4. However:

• This limitation does NOT apply to claims covered by Section 9.4 of the Terms of Service (gross negligence, willful misconduct, privacy breaches, etc.)
• If we commit a fundamental breach of contract (substantial failure to deliver core service functionality), you may have additional remedies as determined by applicable law
• Service credits do not count against the liability cap in Section 9.2 of the Terms of Service

6.4 Requesting Service Credits

To request a service credit, email [email protected] within 60 days of the end of the affected month with:

• Your account email address
• The calendar month in question
• Date(s) and time(s) of the downtime you experienced
• Description of how the downtime affected you
• Any relevant error messages, screenshots, or logs

We will review your request, verify the downtime against our monitoring data, and respond within 15 business days with a decision. Approved credits are applied to your next invoice at our sole discretion. We reserve the right to deny requests that do not meet the conditions in Section 6.2 or where the downtime falls within the exclusions in Section 1.3.

7. Scheduled Maintenance

We perform routine maintenance to improve the Service, apply updates, and enhance security. Scheduled maintenance:

• Is announced at least 48 hours in advance via email and dashboard notification
• Is typically scheduled during low-traffic periods (weekends, late night/early morning Pacific Time)
• Usually targets completion within 2-4 hours
• Does not typically affect your ability to trigger manual failover or your servers' ability to fail over automatically (Agents cache last known state)
• May temporarily affect dashboard access or real-time monitoring updates

Emergency security maintenance may be performed with less than 48 hours notice when necessary to protect the Service or customer data. We will provide as much notice as reasonably possible and will work to minimize disruption.

8. Relationship to Terms of Service

This SLA is incorporated into and forms part of the Terms of Service. In the event of any conflict between this SLA and the Terms of Service:

• This SLA governs service level commitments, uptime targets, and service credits
• The Terms of Service govern all other matters, including liability limitations, indemnification, and dispute resolution
• The Privacy Policy governs privacy and data protection matters

The warranties, disclaimers, and limitations of liability in the Terms of Service apply to this SLA. Service credits under this SLA do not limit or waive any other rights or remedies available under the Terms of Service or applicable law.

9. Changes to This SLA

We may update this SLA from time to time. We will:

• Post the updated SLA on our website at tergum.ca/sla
• Update the "Last Updated" date at the top
• Provide at least 30 days' advance notice by email for material changes that reduce service levels or remedies
• Display a prominent notice in the dashboard for significant changes
• Treat continued use of the Service after the effective date as acceptance of the modified SLA.

Material changes include: reductions in uptime commitments, increases in target response times, reductions in service credits, or new exclusions. Improvements to service levels or credits do not require advance notice. Continued use of the Service after the effective date constitutes acceptance of the modified SLA.

10. Contact

For SLA-related inquiries, to report an incident, or to request service credits:

Email: [email protected]
Subject line: "SLA Inquiry" or "Service Credit Request"
Website: https://tergum.ca

For general support: [email protected]
For legal inquiries: [email protected]
For privacy matters: [email protected]