Service level agreement
The Pilae SLA: a 99.9% monthly availability commitment per production app, measured by Pilae probes, with service credits and response targets per plan.
Last updated
This service level agreement (“SLA”) describes the availability commitment, service credits and response targets that Pilae SA, Rue de Bourg 27, 1003 Lausanne, Switzerland (“Pilae”) gives for the apps it operates for a customer. It applies as set out in the customer’s contract. Where the contract says something different, the contract prevails.
1. Scope
1.1 This SLA covers each production app that Pilae operates for the customer under an Essential, Business or Enterprise plan, whether it runs in Pilae Cloud, on the customer’s premises, in a hybrid setup or in an air-gapped site.
1.2 Staging, test and pilot environments, and apps the contract marks as non-production, are not covered by the availability commitment. They are still monitored and supported.
1.3 For apps on the customer’s premises, the commitment applies where the machines, power and network meet the specification agreed in the contract. See on-premises deployment and the shared responsibility model.
2. Availability commitment
2.1 Pilae commits to a monthly availability of 99.9% for each production app, on every plan.
2.2 In a 30-day month, 99.9% allows about 43 minutes of unavailability.
2.3 Monthly availability is calculated per app as:
availability = (minutes in the month − unavailable minutes) ÷ minutes in the month × 100Minutes excluded under section 6 are not counted as unavailable.
3. How availability is measured
3.1 Availability is measured by Pilae’s monitoring. Each app is probed every 60 seconds on a health check agreed for that app. Where the app offers one, the probe calls its health endpoint and checks the answer, not only that a page loads.
3.2 An app is unavailable from the first of two consecutive failed probes until the next successful probe.
3.3 For air-gapped sites, the probes run inside the site and the results are collected in the console under the same rules.
3.4 The measurements are recorded in the console. Each month the customer receives a report per app with its availability, the incidents and their causes, and the changes applied. See monitoring.
3.5 If the customer’s own measurements differ from Pilae’s, the parties review both in good faith. Pilae’s probe records are the reference unless they are shown to be wrong.
4. Service credits
4.1 If an app’s monthly availability falls below 99.9%, the customer receives a service credit on the monthly fee for that app:
| Monthly availability of the app | Service credit |
|---|---|
| Below 99.9%, and at least 99.5% | 10% of the app’s monthly fee |
| Below 99.5%, and at least 99.0% | 25% of the app’s monthly fee |
| Below 99.0% | 50% of the app’s monthly fee |
4.2 Credits for one app in one month are capped at 50% of that app’s monthly fee.
4.3 Credits are deducted from a later invoice. They are not paid out in cash, except on termination where no further invoice will be issued.
4.4 The customer’s contract may set different thresholds or amounts. Where it does, the contract applies.
4.5 Service credits are the customer’s remedy for missed availability. They do not limit any right the customer has under the contract for other breaches, or any liability that cannot be limited under Swiss law.
5. Maintenance windows
5.1 The customer and Pilae agree one or more maintenance windows per environment in the contract. Updates, upgrades and planned changes are applied inside those windows.
5.2 Every change is planned by the Pilae Agent, sent for the customer’s approval, applied after a verified backup is taken, and recorded in the audit log.
5.3 Planned maintenance is announced in the console at least five business days in advance.
5.4 When a security fix cannot wait for the next window, Pilae proposes emergency maintenance at once. It is applied only with the customer’s approval, unless the contract authorises Pilae to act without it.
6. Exclusions
The following minutes do not count as unavailable:
6.1 Planned maintenance inside an agreed window, announced as set out in section 5.
6.2 Emergency maintenance the customer approved under section 5.4.
6.3 Unavailability caused by the customer, its users or its contractors, including changes made outside the Pilae Agent, and instructions Pilae advised against in writing.
6.4 Unavailability caused by a fix or change that Pilae proposed and the customer declined or postponed.
6.5 For apps on the customer’s premises, failures of the customer’s hardware, power, cooling, network or internet connection, or hardware that does not meet the agreed specification.
6.6 Failures of third-party services the customer chose and that Pilae does not operate, such as an external AI model API, the customer’s identity provider or the customer’s DNS.
6.7 Suspension under the acceptable use policy or the contract, including for unpaid invoices after notice.
6.8 Events beyond Pilae’s reasonable control, including natural disasters, war, acts of authorities, and large-scale network attacks that reasonable protection could not prevent.
6.9 Features the contract marks as preview or beta.
7. Support hours
7.1 Monitoring and alerting run around the clock on every plan. Alerts reach Pilae engineers at any hour.
7.2 Support hours depend on the plan:
| Plan | Support hours |
|---|---|
| Essential | Business hours: 08:00 to 18:00 Swiss time, Monday to Friday |
| Business | Extended hours: 07:00 to 20:00 Swiss time, Monday to Friday |
| Enterprise | Around the clock, every day of the year, for Severity 1 and 2; extended hours for Severity 3 and 4 |
7.3 Public holidays in the canton of Vaud are outside business and extended hours.
8. Severity levels
| Severity | Definition |
|---|---|
| Severity 1, critical | A production app is down or unusable for all users, or data is at risk, and there is no workaround. |
| Severity 2, high | A production app is seriously degraded, or a main function fails for many users, and a workaround is limited. |
| Severity 3, normal | A function fails or behaves wrongly with a workaround available, or a non-production environment is down. |
| Severity 4, low | A question, a request for a change, or a minor defect with no effect on daily use. |
Pilae sets the severity when it opens an incident from an alert. When the customer reports an issue, it proposes a severity and Pilae confirms it or explains the change.
9. Response targets
9.1 The response target is the time between Pilae receiving an alert or a customer report and a Pilae engineer starting work and telling the customer’s named contact what is affected. Times run within the support hours of the plan.
| Severity | Essential | Business | Enterprise |
|---|---|---|---|
| Severity 1 | 4 business hours | 1 hour | 30 minutes, around the clock |
| Severity 2 | 8 business hours | 2 hours | 1 hour, around the clock |
| Severity 3 | 2 business days | 1 business day | 4 business hours |
| Severity 4 | 5 business days | 3 business days | 2 business days |
9.2 For Business, all targets run within extended hours. For Enterprise, the Severity 1 and 2 targets run around the clock and the Severity 3 and 4 targets within extended hours. “Business hours” and “business days” in the table follow the hours of the plan in section 7.
9.3 After the first response, Pilae updates the named contact at regular intervals until the incident is resolved. Every Severity 1 incident gets its own written report with the cause and the measures taken.
9.4 The customer’s contract may set other response targets. Where it does, the contract applies.
10. Backups and recovery
10.1 Every app is backed up daily, encrypted and stored offsite in the country the customer chooses. Restores are tested every month and the result is recorded in the console.
10.2 Retention follows the plan. Recovery point and recovery time objectives (RPO and RTO) are set in the contract, per app. See backups and recovery.
11. How to claim a service credit
11.1 The customer claims a credit through the console or by email to hello@pilae.com, within 30 days after the end of the month concerned.
11.2 The claim names the app, the month and, where known, the times of the unavailability.
11.3 Pilae answers within ten business days with its probe records for the period. An accepted credit is deducted from the next invoice.
11.4 If the parties disagree, they escalate to their named contacts before any other step.
12. Changes to this SLA
Pilae may update this public SLA. A change does not reduce the commitments in a signed contract during its term, unless the customer agrees in writing.
13. Governing law and jurisdiction
This SLA is governed by Swiss law. The place of jurisdiction is Lausanne, Switzerland, subject to any mandatory place of jurisdiction.