Policies and legal docs

We promise to do everything we can to keep your Apps up. Uptime is our bread-and-butter. We proud ourselves for a good uptime track record. Please see our public status page with a full history of incidents. But let's be realistic. Things will go wrong one day. The following SLA defines the refund you'll get for downtime:

The source of this document is here: github.com/fortrabbit/legal/blob/master/service-level-agreement.md.

Service level agreement of fortrabbit

last reviewed: June 13th, 2018

  1. fortrabbit will use commercially reasonable efforts to make the fortrabbit platform available with a monthly uptime percentage (defined under sec. 2 of this SLA) depending on the product chosen by you during any monthly billing cycle. In the event fortrabbit does not meet the guaranteed uptime, you will be eligible to receive a service credit as described under sec. 6 of this SLA.
    • no uptime guaranteed during trial
    • 99% uptime in general for Universal and Professional development plans
    • 99.9% uptime for scaling Components with two ore more Nodes — Professional production plans
  2. Monthly uptime percentage means the total number of minutes in a monthly billing cycle the fortrabbit storage system was connected to the internet ready to receive and provide information minus the number of minutes of downtime suffered in a monthly billing cycle, divided by the total number of minutes in a monthly billing cycle.
  3. The provider reserves the right to temporarily restrict the access of certain internet users or internet user groups to the provided services, if the security of network operations, integrity of the network and/or hosted data is endangered.
  4. The provider shall inform the customer about all planned network operations in advance.
  5. The provider endeavors to schedule planned network operation in low traffic periods.
  6. In the case of non-compliance of a certain service level, the provider provides an amount of credit granted under the following conditions:
    1. Credits will be granted if the customer applies within 10 calendar days of the end of the calendar month in a written form (email, fax).
    2. The cumulative granted credits will be calculated by the actual downtime in proportion to the ongoing month.
    3. The cumulative granted credits of all service levels shall be restricted of the total of the monthly renumeration of this service.
  7. Any liability for indirect or collateral damages as well as following damages, loss of profit, service interruption, loss of data or information is being granted under the fortrabbit Terms Of Service only.
Print and download a PDF of this

Do you like our policies, or wonder about changes, or found a typo? See the fortrabbit legal repo on GitHub.

Our humble opinion

A legal page like this is probably not the right place to be opinionated. Still, please consider:

As far as we know and see: Any SLA will not prevent you from having downtime in reality. A service level agreement is just a set of rules on what will happen when the downtime has happened.

Any regular SLA for hosting will not cover the costs of your lost business. It only will cover the costs for not providing the service during a downtime. In other words: When you pay 300€ a month for hosting and your website was down for a day, you will get back 10€.

Also, from our experience, there are many grey areas in hosting. We, for example, have different services. Let's say deployment is down, or our Dashboard is down - how is that measured? Or there is an incident making the website respond slower as usual. Sometimes it's not easy to measure and track a downtime. For example, a certain monitoring of our system is constantly reporting back "200 OK", while a Pingdom alert from a client might paint a different picture of the same situation. Our SLA (like any other) defines that we are responsible to identify what ever is downtime or not.

Actual downtime clients are experiencing is often caused by their own "coding mistakes" — by not making proper use of the available resources. Think slow database queries for example, which might work while testing, but not in production at a certain point of traffic. In most cases a "500 server error" is not a hardware problem with the hosting but a runtime error in PHP caused by the specific code of the client. Such errors can be resolved independently by analyzing the logs files, which clients have access to. We are happy to discuss and research such problems together with our clients.

Also, there are many technical measurements which can be taken by the developers to dramatically lower the chances of having any downtime at all. Our multi-node production plans are offering high availability when correctly implemented. For CMS systems such as Craft, it's often possible to cache the whole frontend in a CDN by using edge caching with a third party service such as Cloudflare.