This Service Level Agreement ("SLA") sets out the commitments MantisOps makes for availability and support of the cloud platform that powers MantisRMM and Mantis360. It is incorporated by reference into the Terms of Service and any Master Service Agreement signed with a customer.
MantisOps commits to the following monthly uptime targets for the cloud platform:
| Plan | Monthly uptime target |
|---|---|
| Trial | Best effort — no SLA |
| Standard (self-serve subscription) | 99.5% |
| Enterprise (signed MSA) | 99.9% — custom SLA available on request |
Uptime is calculated as (total minutes − downtime minutes) / total minutes × 100. Downtime means the cloud API and web dashboards are unavailable for all users on the plan in question. Partial degradation — a specific feature unavailable, single-region slowness, scheduled maintenance — does not count as downtime.
The following are excluded from uptime calculations:
mantisops.net or downstream networking issues at the customer's siteIf we fail to meet the uptime commitment for your plan in a given calendar month, you are eligible for a service credit:
| Monthly uptime (Standard plan) | Credit |
|---|---|
| 99.0% – 99.49% | 10% of monthly fee |
| 95.0% – 98.99% | 25% of monthly fee |
| Below 95.0% | 50% of monthly fee |
To claim a credit:
Maximum credit: 50% of the monthly fee per calendar month.
How we categorize support requests determines the response-time commitment in section 5.
| Severity | Definition | Example |
|---|---|---|
| P0 — Service down | The cloud platform is unavailable for all users on your tenant; you cannot sign in or use any product feature. | API returning 5xx for every request; complete login failure |
| P1 — Major degradation | A core function is broken for your tenant — scans not running, agents disconnected fleet-wide, billing portal returning errors. | Probe will not connect; remote desktop fails for every agent |
| P2 — Single-feature issue | One feature is broken or behaves incorrectly; workarounds exist; other parts of the platform work normally. | One report type fails to generate; one workflow step type errors |
| P3 — Question or minor issue | Cosmetic bug, documentation question, feature request, or "how do I…" question. | UI alignment, asking how to configure a scan profile |
Response time is the time between you opening a support ticket and our team's first substantive reply (not auto-acknowledgement). Business hours are Monday–Friday, 9am–6pm Eastern Time, excluding US federal holidays.
| Severity | Standard plan | Enterprise (signed MSA) |
|---|---|---|
| P0 — Service down | 4 business hours | 1 hour, 24×7 |
| P1 — Major degradation | 8 business hours | 2 hours, 24×7 |
| P2 — Single-feature issue | 2 business days | 4 business hours |
| P3 — Question or minor issue | 3 business days | 1 business day |
How to reach us:
portal.mantisops.net, rmm.mantisops.net, and 360.mantisops.net during business hours.The MantisRMM agent and Mantis360 probe are software you install on your own infrastructure. Their availability depends on your local environment — network connectivity, hardware health, operating-system updates, and other tooling on the host. These factors are outside the scope of this SLA.
The cloud platform that the agent and probe connect to (api.rmm.mantisops.net and api.360.mantisops.net) is covered by this SLA. If you observe a connectivity issue and the public status page shows the platform is healthy, the cause is most likely local — agent log files in %ProgramData%\MantisOps are the right place to start.
We will provide at least 24 hours' advance notice for planned maintenance that may cause downtime. Maintenance windows are typically scheduled outside US business hours (evenings, weekends). Notice will be sent to the email address registered on your account and posted to the in-app banner system.
status.mantisops.net and will display current service availability, ongoing incidents, and the past 90 days of incident history.For the rare scenario where the cloud platform suffers a serious outage requiring restore-from-backup (e.g., region-wide infrastructure incident, accidental data deletion), we commit to the following targets:
| Metric | Target | Means in plain English |
|---|---|---|
| RPO (Recovery Point Objective) | ≤ 24 hours | In a worst-case restore, you would lose up to 24 hours of data — matching our nightly off-platform backup cadence. Most restores can use Cloudflare's in-platform point-in-time recovery and lose far less. |
| RTO (Recovery Time Objective) — single-tenant restore | ≤ 4 hours | Restoring one tenant from backup (e.g., after an accidental data deletion). |
| RTO — full-platform restore | ≤ 24 hours | Standing the platform back up after total infrastructure loss (extremely rare scenario covered by our documented runbook). |
We retain off-platform backups for 30 daily, 12 monthly, and 7 yearly snapshots. Transactional state (subscriptions, payments) is also held by our payment processor (Stripe), which is independent of our hosting infrastructure.
We may modify this SLA from time to time. Material changes will be announced via email and the in-app banner at least 30 days before they take effect. Existing customers retain the SLA in force at the time of their last renewal until that subscription term ends.
← Back to MantisOps