Commitment
Service Level Agreement
We target 99.9% monthly uptime on both plans. Where we fall short, you receive a service credit. The schedule differs between plans, and it is set out in full below.
The schedule
The commitment
| Monthly uptime | Shared | Dedicated |
|---|---|---|
| 99.9% or above | No credit | No credit |
| Below 99.9%, at least 99.5% | No credit | 10% |
| Below 99.5%, at least 95.0% | 10% | 25% |
| Below 95.0% | 25% | 100% |
Credits are a percentage of one month of fees. Uptime is measured over one calendar month, so credits are calculated against one month, and on an annual plan that means one twelfth of your annual fee. So, for example, a Shared annual plan at $2,400/year is effectively $200/month for this purpose.
Claims
You do not have to ask
Most service level agreements put the work on you.
You have to notice the outage, calculate the uptime yourself, find the claim process, and file inside a window. Amazon, for instance, requires a claim with supporting documentation by the end of the second billing cycle after the incident. Miss the window and the credit simply does not happen.
.
Ours are automatic.
The platform measures uptime, attributes every disruption, calculates any credit owed, and grants it. No ticket, no form, no deadline, no evidence to assemble on your end.
The credit appears in your customer portal in the month the shortfall happened, where you cannot miss it.
It is applied against the next charge on your account, whether that is your renewal or a mid-term addition of accounts or Connectors.
If you disagree with a measurement or an attribution, raise it and a human will look at it properly. In the ordinary course, nobody needs to.
On why this is a credit rather than a refund.
We looked seriously at simply sending the money back. In several countries, a cash refund against an invoice already issued creates a taxable event for the customer and generates accounting work nobody asked for. A credit avoids all of that.
Scope
What this covers, and what it does not
-
What this covers
The components Syncplify operates: availability of the SFTP.cloud Head listeners, measured per service.
-
What this does not cover
Your Storage Connector, your storage, and your network. Those run on infrastructure you own and operate, and we have no ability to keep them available.
We are stating that plainly here rather than burying it, because an argument about scope during an outage helps nobody.
Attribution
How we decide whose fault it was
Our monitoring watches the whole path, both the components we run and the reachability of your Connector. Every disruption is attributed to one side or the other, automatically.
Only disruptions attributable to Syncplify count against this agreement.
Your portal shows that attribution for every incident, whichever way it falls. When the fault was ours, it says so, in the same place and with the same prominence as when it was not.
Exclusions
Two things that do not count
-
Events nobody could have prevented
Some outages are not anyone's to fix. A fire in a datacenter. A major failure in internet routing or in a large content delivery network. A natural disaster, an act of war, a government order, a general failure of the public internet, a labor dispute or an outage at an upstream infrastructure provider. Where an event was outside our reasonable control, and there was nothing we could sensibly have done to prevent it or design around it, it does not count against this agreement.
We know this is the clause every company reaches for when it wants out of something. We intend to use it narrowly, and we will tell you which category an incident fell into rather than leaving you to guess.
-
Changes you asked us to make
Some things cannot be done without a short interruption. Moving from a Shared plan to a Dedicated one, for example, builds you a new environment and moves your service onto it, and there is no honest way to do that with zero downtime. Where you have asked for a change and we have carried it out, the interruption it causes does not count against this agreement.
Measurement
How we measure
What is measured.
The availability of each protocol handler, SFTP, FTPS, FTPES and HTTPS, on each Head serving your site.
How.
Probers running outside the Heads they watch test each protocol handler once every minute.
When a minute counts as down.
A protocol handler is counted as down for a given minute only when more than half of the probers agree that it was. One prober having a bad minute does not put your service into an outage.
Your uptime is the worst protocol, not the average.
If SFTP sits at 98.9% for a month and everything else is at 100%, your uptime for that month is 98.9%. We do not average the protocols together and we do not let a healthy one cover for a struggling one. Your partners connect over the protocol they connect over, and that is the one that matters.
Monthly uptime.
The percentage of minutes in the calendar month, measured in UTC, in which your service was not counted as down.
Scheduled maintenance.
Announced in advance and excluded from these figures. You will still see it in your portal, marked as maintenance, so the record stays complete even where the agreement does not apply.
Where to see all of this.
Your uptime, every incident, its attribution and any credit owed are in your customer portal. There is no public status page, because there would be nothing meaningful to put on one. Your site runs on its own infrastructure and your uptime is yours, rather than an average of everybody's.
Exclusions.
See “Two things that do not count,” above.
Changes
Changes to this agreement
We may update this agreement from time to time. When we do, two things will always be true.
You get notice.
.
We email account administrators when a change takes effect.
Reductions apply at renewal, never mid-term.
If a change reduces what we commit to here, it applies to your account from your next renewal date rather than immediately. Anything you have already paid for keeps the terms it was sold under. The only exception is a change we are required to make by law or one that is necessary to address a security risk, and if that ever happens we will tell you which it was and why.
Improvements take effect straight away. There is no reason to make you wait for those.