Our measurable commitment to availability, support, and recovery. Applies to all contracted plans. You can see real-time service health on the Status page.
| Metric | Commitment | Detail |
|---|---|---|
| Monthly uptime | 99.5% | max ~3.6 h downtime/month |
| Scheduled maintenance | Sun 2–4 AM PET | notified 24 h in advance and published as a scheduled incident on the Status page |
| Monitoring | every 5 min | automated database and disk check, logged for the Status page |
| RPO | 24 h | recovery point: the backup is daily, so the maximum loss is the day in progress |
| RTO | 4 h | target recovery time; not verified by a restore drill |
How it is measured, and what the measurement cannot see. An automated process checks the platform every 5 minutes and records the result; the Status page publishes that history and computes uptime over the last 30 days. That computation has a blind spot, and we state it here instead of hiding it: the checker runs on the very server it watches, so a total outage produces no failed checks —it produces none at all— and on its own does not lower the published percentage. So an outage you observe counts even if the percentage does not reflect it: report it through support and it is reviewed by hand and published as an incident.
| Severity | Description | Response | Target resolution |
|---|---|---|---|
| 🔴 Critical | System down, login impossible, data loss | 2 hours | 8 hours |
| 🟠 High | Core feature down (grades, attendance) | 8 hours | 24 hours |
| 🟡 Normal | Non-critical bug, visual fix, technical question | 24 hours | 5 days |
| 🟢 Low | Suggestion, feature request, general question | 48 hours | Backlog |
Channels: in-app widget (24/7 logging), WhatsApp and support email, attended Mon–Fri 8:00–18:00 PET. How it is checked: the widget records the ticket with its date and time, so when help was requested is on record; however no system currently measures first-response time automatically, so these targets rest on the ticket record and not on a metric that computes itself.
Daily automatic backups (3:00 AM PET) of every database, kept for 14 days (the cron prunes older ones). Encrypted connections (HTTPS/TLS 1.2+), parameterized queries for every piece of input data —table and column names, which cannot be parameterized, are validated against closed allowlists—, CSRF on forms and bcrypt auth with optional 2FA. The Service is built to comply with Law No. 29733; what is already done and what is still pending is set out, unvarnished, in the Trust Center.
If monthly uptime falls below 99.5% for reasons attributable to Campus, credits apply to the following month's invoice:
| Monthly uptime | Credit |
|---|---|
| 99.0% – 99.5% | 5% of the month |
| 95.0% – 99.0% | 10% of the month |
| < 95.0% | 25% of the month |
Exclusions: announced scheduled maintenance, force majeure, third-party service failures (AI providers), unauthorized client modifications, and trial/demo accounts.
How to claim the credit. The credit is not applied automatically: billing neither computes nor deducts it on its own. It is requested through the support channel within the month following the breach and settled against the history published on the Status page and the recorded incidents —including those reported by the school and missed by the automated checker, due to the blind spot explained in §1—.