Service Level Agreement

Summary

Uptime guarantee

What counts as uptime

Your Odoo instance is up when it is reachable over HTTP(S) and served by the infrastructure stack we manage. We measure this with our own monitoring from external locations. Monthly uptime is the share of minutes in the calendar month that your instance is up.

Application errors and slow performance are not downtime. Downtime from the events under Exclusions is left out of the calculation.

Cloudpepper servers

When you provision an instance, you choose where it runs: on a Cloudpepper server (High Performance or Dedicated Performance), or on your own infrastructure. Cloudpepper servers are the Cloudpepper-provided infrastructure, and these uptime guarantees are the availability objectives referred to in the Customer Terms of Service. They apply per month:

Cloudpepper servers run in the data centers of ISO 27001-certified infrastructure providers, with redundant power, network and storage. Where available in your region, these data centers are Tier III or equivalent. Dedicated Performance servers run on infrastructure with N+1 redundancy and a 99.999% provider SLA. You choose the region where your production instance runs.

Infrastructure failures. Cloudpepper servers are monitored 24/7. Hardware, network, power and storage failures are handled around the clock, on every plan, without a report from you. Support for your Odoo instance follows the Support section.

Your own infrastructure

You can also run Odoo on your own cloud account (for example AWS, Azure, Google Cloud or Hetzner) or on a server with a supported operating system that you connect over SSH, and manage it through My Cloudpepper. Deployment, monitoring, backups, support and updates work the same way. Your provider supplies the compute, storage and network.

The availability of that infrastructure falls under your agreement with your provider. We are not a party to it. The uptime guarantee and service credits in this SLA apply to Cloudpepper servers.

On your own infrastructure, these commitments continue to apply, within the limits under Operational access. Deployment, backups, updates and recovery need access to working infrastructure.

• Deployment, configuration, monitoring and management of your Odoo instance.
• Support and updates, as described under Support.
• Backups on the schedule you configure, to either storage option.
• The recovery target, when your provider can supply a replacement server.

Service credits

If the monthly uptime of an instance on a Cloudpepper server falls below its guarantee, you can request a credit on your next invoice:

How to claim. Email support@cloudpepper.io within 30 days of the incident. Include the affected instance, the downtime period and any ticket numbers from My Cloudpepper.

How we check. We check the downtime against our monitoring records and incident tickets. We credit downtime that our monitoring confirms, that matches an incident you reported, or that is part of a platform incident we declared.

What credits cover. Credits apply to the recurring Cloudpepper hosting fee of the affected instance. They do not apply to third-party infrastructure charges, Odoo licences, domain registrations, add-ons, usage-based charges (including backup storage overages), taxes or professional services. Credits go on future invoices and are not paid out in cash. Total credits are capped at 100% of the instance’s monthly fee per calendar month.

Who can claim. Credits are available to accounts that are paid up and not suspended or in material breach of the Customer Terms of Service. Free trials do not earn credits.

Backups and disaster recovery

You set the backup schedule and retention of each instance. Schedules run from hourly to monthly, and you can combine several.

Where backups are stored

You choose the storage. Both options are available on Cloudpepper servers and on your own infrastructure:

• Cloudpepper Managed Backup Storage: data centers in France, separate from your production server and encrypted at rest by default. Storage charges depend on retention and backup volume; see our pricing page.
• Your own storage: any SFTP server or S3-compatible object storage you control. You manage its credentials, capacity, retention and encryption at rest.

How much data you could lose (RPO)

Your recovery point is your most recent successful backup.

How fast you are back online (RTO)

If your server’s hardware fails completely, recovery takes two steps:

1. A replacement server is provisioned, typically within 20 minutes. You choose where it runs: in another data center, on another server tier or with another cloud provider. On a server you connect over SSH, you provide the replacement.
2. We restore the most recent successful backup from your storage destination.

Recovery target: under 1 hour once recovery work starts, for small and medium instances, when a recent successful backup exists, the backup storage is reachable and a replacement server can be provisioned. Large databases, very large filestores, slow customer-controlled storage, provider-wide incidents, DNS propagation and non-standard setups can take longer. When backups are stored apart from the live server, you can recover after a server or data center failure, as long as the backup storage and a replacement server are available. Like our first-reply targets, the recovery target is a reasonable-efforts target: a missed target alone is not a breach and creates no right to service credits or damages.

Security

• Encryption in transit: the public web connections we manage use TLS with modern cipher suites.
• Encryption at rest: Cloudpepper Managed Backup Storage encrypts all backups at rest by default.
• Isolation: each Odoo instance runs in its own environment. Databases are never shared between customers.
• Hardened systems: minimal, hardened Linux configurations with unattended security updates and a firewall.
• Data breaches: we notify you of personal data breaches as set out in Section 8 of our GDPR & Data Processing Agreement.

Support

Support covers every paid plan managed through My Cloudpepper, on Cloudpepper servers and on your own infrastructure.

Coverage and first-reply targets

• Server failure: a hardware, network, power or storage failure on a Cloudpepper server. Our infrastructure providers’ data center engineers handle it, and the uptime guarantee applies.
• Critical: a failed deployment, update or restore leaves your production instance unavailable.
• High: other production problems, such as a failed backup, a failed deployment while your instance keeps running, a badly degraded instance or a blocked production-critical operation.
• Normal: support questions and non-blocking issues, such as staging instances, configuration and how-to questions. Our AI assistant helps with how-to questions around the clock.

How targets work. A first-reply target is the time until the first reply from a Cloudpepper engineer, counted from when your report reaches us with enough information to start. We use reasonable efforts to meet every target. A missed target alone is not a breach and creates no right to service credits or damages.

Business hours are 09:00–18:00 Brussels time (CET/CEST), Monday to Friday, except Belgian public holidays. One business day is nine business hours.

During an incident

During the hours that apply to your plan and priority, we use reasonable efforts to keep working on the incident and to give you clear status updates. During a Critical incident, we aim to give you an estimated time for the next update.

Operational access

To fix an incident, we need access to the instance and its infrastructure. Access can be blocked by changes on your side (for example firewall or SSH settings), a provider outage, network or DNS problems, or other causes outside our control. We still aim for the first-reply target, and work that needs access resumes when access returns. Meanwhile, we help with diagnosis and provider escalation as far as we can.

What support covers

Your own infrastructure. Server, network and data center failures fall under your provider’s SLA. Platform and Odoo-level incidents stay in scope.

Data integrity. Covers backup integrity and restore capability. Application-level data issues are outside standard support and can be offered as professional services. Examples: incorrect values produced by your code or modules, business-logic errors, slow queries on your customisations, or recovering records that users deleted, other than by restoring a backup.

Reclassification. After triage, we can move a report to the priority that matches the definitions above and tell you why, for example when it is caused by your code, custom modules, integrations, configuration changes, installed software, non-production instances or other causes on your side. The first-reply clock keeps running. If a Critical report turns out to have a cause on your side, and your plan or order form provides for it, we can charge emergency support or professional services fees before we continue the work.

Shared responsibility

To make these commitments achievable, you also:

• Configure backup schedules that match how much data you can afford to lose, with enough backup storage for your retention.
• On your own backup storage: keep valid credentials, enough capacity and encryption at rest.
• Test regularly that your backups restore; we recommend every quarter.
• Approve or apply Odoo updates, module updates or security changes that need your action or consent, without undue delay.
• Check custom and third-party modules for compatibility, security and stability before you deploy them to production.
• Report incidents promptly, with enough detail for us to diagnose them.
• Use multi-factor authentication where available.

Issues on your side are outside standard support and can be handled as professional services.

Exclusions

The uptime guarantee and service credits exclude downtime caused by:

• Your code or data: buggy or misconfigured custom or third-party Odoo modules, application errors, database locks or slow queries caused by your customisations, or unauthorised access.
• Software you install or changes you make over SSH, such as alternative web servers, custom daemons, extra system packages or changes to the operating system configuration.
• Your configuration changes, third-party integrations, or DNS outside our control.
• Denial-of-service attacks against your instances.
• Suspension, deletion or rebuild of an instance at your request.
• Failures of your own backup storage (SFTP or S3).
• Force majeure: natural disasters, war, civil unrest, government action, or systemic internet routing failures outside our or our infrastructure providers’ reasonable control.
• Planned maintenance announced at least 24 hours in advance where commercially reasonable, and scheduled outside local business hours in the region where the server runs. Emergency maintenance for security, stability or provider reasons can happen with shorter notice; we inform affected customers as soon as practicable.
• Your own infrastructure, whose availability falls under your provider’s SLA.
• Incidents not reported to us at the time of the event, unless our monitoring confirms them or we declared a platform incident.

Changes to this SLA

Changes to this SLA follow Section 2 of the Customer Terms of Service, which sets the notice period and your right to cancel. Amendment terms that you agreed with us individually take precedence.

This SLA forms part of the Customer Terms of Service.