Uptime SLA
What we commit to, how it is measured, and what you get if we miss it. Written so you can actually claim it.
Last updated: · Applies to SupportCentral Enterprise, operated by Support IT Ventures.
The commitment
We commit to 99.5% availability per calendar month on paid plans, and 99.9% on our highest plan. We are deliberately not claiming 99.99% — that number requires infrastructure we do not yet run, and publishing it would be a promise we could not keep.
How availability is measured
By external checks against the application's health endpoint, from more than one location, at one-minute intervals. A minute counts as down if two consecutive checks from different locations fail. Monthly availability is (total minutes − down minutes) ÷ total minutes.
What is excluded
- Scheduled maintenance announced by email at least 48 hours in advance. We aim for under two hours a month, outside Indian business hours.
- Anything caused by your own network, device or configuration.
- Third-party services you connect with your own credentials, and outages at your email provider.
- Suspension for non-payment or for breach of the acceptable use policy.
- Force majeure.
Service credits
Claim by writing to billing@supportcentral.in within 30 days of the end of the affected month. Credits are applied to a future invoice, are the sole remedy for unavailability, and are capped at 100% of one month's fee.
| Monthly availability | Credit as a share of that month's fee |
|---|---|
| 99.5% or above | No credit due |
| Below 99.5% but at or above 99.0% | 5% |
| Below 99.0% but at or above 95.0% | 10% |
| Below 95.0% | 25% |
Why 99.5% and not a bigger number
99.5% a month allows about three and a half hours of unplanned downtime. That is what we can stand behind today on the infrastructure we actually run, and we would rather commit to a number we meet every month than publish a larger one and spend our time explaining exclusions.
As the platform grows and the architecture changes, this number will improve, and we will say so here rather than quietly. If your procurement process requires a specific higher figure, talk to us before you buy rather than after.
Planned maintenance
Most changes ship without any downtime at all. Where a release genuinely needs a window, we announce it by email to account owners at least 48 hours ahead, put it on the status page, and schedule it outside Indian business hours. We aim to use under two hours a month and usually use none.
What counts as downtime, and what does not
Downtime means the application is not answering. A single feature being degraded — say, outbound email delayed while everything else works — is an incident we will report and explain, but it is not counted as unavailability unless it makes the service unusable.
We would rather draw that line explicitly than have an argument about it later with a customer who is already having a bad day.
What we do when we miss it
We publish what happened, what caused it and what we changed, on our status page. An incident that we do not explain is an incident we have not finished.
Something here unclear or unfair? Tell us at support@supportcentral.in. We would rather fix the wording than argue about it later. See also Terms, Privacy and Grievance redressal.