Service Level Agreement

Availability, backup, recovery, and support commitments for Odoo environments managed through the My Cloudpepper platform.

Cloudpepper deploys, monitors, manages, and supports your Odoo instance through the My Cloudpepper platform, regardless of where the underlying infrastructure runs. When provisioning your instance, you choose the infrastructure source: Cloudpepper-provided infrastructure (selecting between two performance tiers), or a cloud account you provide yourself (see Customer-Provided Infrastructure below).

Where your instance is deployed on Cloudpepper-provided infrastructure, the following availability objectives apply per tier:

• High Performance — 99.9% monthly availability objective (a maximum of approximately 43 minutes of unplanned downtime per month).
• Dedicated Performance — 99.99% monthly availability objective (a maximum of approximately 4 minutes 22 seconds of unplanned downtime per month), built on infrastructure with a 99.999% provider SLA, N+1 redundancy for core infrastructure components (power, network, and storage), and ISO-certified data centers.

For the purposes of this SLA, “Availability” means the ability of the managed Odoo instance to respond to HTTP(S) requests, as measured by Cloudpepper monitoring from external probe locations. Events falling within the Exclusions section below do not count toward downtime.

You may choose to deploy your Odoo instance on your own cloud account — for example, AWS, Azure, Google Cloud, Hetzner, or any other provider — while still managing it through the My Cloudpepper platform. In this configuration, deployment, configuration, monitoring, backups, support, and updates work identically to deployments on Cloudpepper-provided infrastructure; what differs is the source of the underlying compute, storage, and network resources, and consequently the infrastructure SLA that governs them.

The infrastructure availability of a customer-provided cloud account is governed solely by the SLA between you and your chosen provider. Cloudpepper is not a party to that contract and cannot offer infrastructure availability objectives covering infrastructure we do not operate.

The following Cloudpepper commitments do continue to apply to customer-provided infrastructure deployments, provided your chosen provider remains operational:

• Deployment, configuration, monitoring, and management of your Odoo instance.
• Application-level support, updates, and incident response (per Support SLA).
• Backup execution per the schedule you configure (per Backups & Disaster Recovery), with both backup storage options available.
• RTO objective for instance recovery, subject to your chosen provider’s ability to provision replacement resources.

The 99.9% / 99.99% availability objectives in the Service Availability section do not apply to customer-provided infrastructure deployments — infrastructure availability is governed by your chosen provider’s SLA.

Where your instance is deployed on Cloudpepper-provided infrastructure:

• Instances run in professional cloud data centers designed with redundant power, network connectivity, and storage. Where available in the selected region, data centers are Tier III–certified or equivalent.
• Storage is enterprise-grade with hardware-level redundancy.
• You select your data center region at provisioning, ensuring data residency and latency control.

For customer-provided infrastructure deployments, the equivalent characteristics are determined by the customer’s chosen cloud provider and selected region.

Cloudpepper gives you full control over your backup strategy. For each instance you define:

• Frequency — hourly, every 3 hours, every 6 hours, every 12 hours, daily, every 3 days, weekly, or monthly.
• Retention — how long each backup is kept.
• Multiple parallel schedules — combine policies, e.g. hourly retained 24 hours + daily retained 30 days + monthly retained 12 months.

Backup Storage Options

You choose where backups are stored. Both options are available for all deployments, regardless of whether your Odoo instance runs on Cloudpepper-provided infrastructure or on a customer-provided cloud account:

• Cloudpepper Managed Backup Storage — backups stored in OVH data centers in France, geographically and operationally independent from your production server, and encrypted at rest by default. Storage charges scale with retention length and backup volume — see our pricing page for current rates.
• Customer-controlled storage — any SFTP server or S3-compatible object storage you control. You are responsible for managing credentials, capacity, retention enforcement, and enabling encryption at rest at the bucket or volume level.

Recovery Point Objective (RPO)

Your RPO is determined by the most recent successful backup. With a healthy backup schedule and a reachable storage destination, your maximum data loss window matches your configured frequency (e.g., one hour with an hourly schedule). Backup health is monitored and surfaced via the Cloudpepper dashboard.

Recovery Time Objective (RTO)

In the event of complete hardware failure of your server, recovery follows two steps:

1. Provisioning a replacement server — typically completed within 20 minutes. The replacement may be deployed in a different data center, or on a different deployment tier or cloud provider entirely.
2. Restoring the most recent successful backup from your designated storage destination.

RTO target: under 1 hour for small and medium-sized instances where a recent successful backup is available, the backup storage is reachable, and replacement infrastructure can be provisioned without provider-side constraints. Larger databases, very large filestores, customer-controlled backup destinations with limited transfer speeds, provider-wide incidents, DNS propagation delays, or non-standard configurations may require additional time. Because backups are stored independently of the live server, recovery is not blocked by the original infrastructure or data center being unavailable.

• Encryption in transit — all Cloudpepper-managed public web connections are protected with TLS, modern cipher suites, and regularly tested configurations. Customer-managed services, custom mail servers, and third-party integrations may require additional configuration.
• Encryption at rest — Cloudpepper Managed Backup Storage encrypts all backups at rest by default. For customer-controlled storage destinations (SFTP/S3), encryption at rest is the customer’s responsibility and should be enabled at the bucket or volume level.
• Isolation — every Odoo instance runs in its own dedicated environment; no shared databases between clients.
• Hardened systems — minimal, hardened Linux configurations with unattended security updates and firewall protection. Customers with SSH access who modify these defaults are responsible for the security implications of their changes.
• Credentials — user passwords are protected using strong cryptographic hashing (currently PBKDF2-based via Odoo’s authentication framework) consistent with industry best practices.

Cloudpepper provides tiered support based on the severity of the issue. Support coverage applies to all deployments managed through the My Cloudpepper platform, regardless of infrastructure source. Reporting channels differ by severity, and response time SLAs apply only to requests submitted through the channel designated for that severity:

• P1 and P2 incidents — report via My Cloudpepper > Support > “I have an incident”. Incidents are routed to our DevOps team for priority triage. To engage our 24/7 on-call engineering rotation for time-critical production issues, select “Critical impact” and request on-call engineering paging when submitting the incident.
• P3 and P4 questions and general troubleshooting — support@cloudpepper.io or in-app chat. These channels are not monitored 24/7 and are not appropriate for time-critical incidents.

Severity	Definition	Initial response	Coverage
P1 — Critical	Production instance unavailable, severe data integrity issue	30 minutes	24/7
P2 — High	Significant degradation, partial unavailability with workaround	2 business hours	Business hours (Brussels time)
P3 — Medium	Non-blocking issue, configuration questions	1 business day	Business hours (Brussels time)
P4 — Low	Feature requests, general questions, documentation	2 business days	Best effort

P1 24/7 response. The 30-minute initial response and 24/7 coverage for P1 incidents apply when the incident is submitted with Critical impact selected and on-call engineering paging requested. P1-severity incidents submitted without on-call paging selected are handled by the DevOps team with priority triage during business hours, with response times equivalent to P2.

Initial response time measures the interval from receipt of a complete report through the appropriate channel for its severity to first substantive reply from a Cloudpepper engineer (auto-acknowledgements do not count). Business hours are 09:00–18:00 Brussels time, Monday to Friday, excluding Belgian public holidays.

P1 scope. P1 coverage applies to production-blocking incidents within Cloudpepper’s operational control — including the Cloudpepper management platform, our deployment automation and monitoring systems, and (for instances on Cloudpepper-provided infrastructure) the underlying infrastructure itself. For instances on customer-provided cloud accounts, infrastructure-level incidents are governed by the customer’s chosen provider’s SLA and fall outside P1 scope; Cloudpepper platform and Odoo-level incidents remain in scope. Issues caused by customer code, custom modules, third-party integrations, customer configuration changes, customer-installed software, non-production instances, or customer-caused incidents may be reclassified following triage. Where a P1 incident is determined after triage to be caused by customer-side issues outside the scope of P1 coverage, Cloudpepper may reclassify the incident and, where applicable under the Customer’s plan or order form, apply emergency support or professional services fees before continuing remediation work.

Resolution times are not committed because resolution complexity varies by incident. We commit to active engagement and clear status updates throughout the lifecycle of any incident. Support is provided in English, French, Dutch and Spanish.

If your monthly availability falls below the objective for your tier, you may request service credits applied to your next invoice:

• Below your tier objective, down to 99.0% — 5% credit on the affected instance’s monthly fee.
• Below 99.0%, down to 95.0% — 10% credit on the affected instance’s monthly fee.
• Below 95.0% — 25% credit on the affected instance’s monthly fee.

How to claim. Email support@cloudpepper.io within 30 days of the incident, including the affected instance, downtime period, and any incident ticket number(s) from My Cloudpepper. Credits are applied to future invoices and are not redeemable for cash. Total credits are capped at 100% of the monthly fee for the affected instance per calendar month.

Verification. Downtime is verified using Cloudpepper monitoring records, supported where applicable by the corresponding incident ticket(s) reported via My Cloudpepper. Credits will not be issued for downtime that cannot be verified by Cloudpepper monitoring or reasonably correlated with an incident report, except where the downtime forms part of a Cloudpepper-declared platform incident or has been independently verified by Cloudpepper monitoring.

Eligibility. Service credits are available only to customers whose accounts are current on payment and not subject to suspension or material breach of the Customer Terms of Service. Credits do not apply to free trials, suspended accounts, or unpaid invoices.

Scope. Credits apply only to the recurring Cloudpepper hosting fee for the affected instance, excluding third-party infrastructure charges, Odoo licenses, domain registrations, add-ons, usage-based charges (including backup storage overages), taxes, and professional services. Service credits apply only to instances deployed on Cloudpepper-provided infrastructure, since the availability objectives apply only to those deployments.

Service credits are the sole and exclusive remedy for any failure to meet the availability objectives in this SLA.

The availability objectives and service credits do not apply to outages caused by:

• Customer-side factors: misconfigured or buggy custom or third-party Odoo modules, application-level errors triggered by customer code or data, database locks or query performance issues caused by customer customisations, or unauthorised access.
• Customer-installed software or modifications made via SSH access, including (without limitation) the installation of alternative web servers, custom daemons, additional system packages, or changes to system or operating system configuration.
• Customer configuration changes, third-party integrations, or DNS issues outside Cloudpepper’s control.
• Denial of service attacks against customer instances.
• Customer-initiated suspension, deletion, or rebuild of an instance.
• Failures of customer-provided storage destinations (SFTP/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, scheduled outside business hours in the deployment region. Emergency maintenance required for security, stability, or provider-related reasons may be performed with shorter notice; affected customers will be informed as soon as practicable.
• Customer-provided cloud infrastructure, where infrastructure availability is governed by the customer’s chosen provider’s SLA.
• Incidents not reported through the incident channel (My Cloudpepper > Support > “I have an incident”) at the time of the event, unless independently verified by Cloudpepper monitoring or declared by Cloudpepper as a platform incident.

To ensure these objectives are achievable, customers are responsible for:

• Configuring backup schedules appropriate to their data loss tolerance and provisioning sufficient backup storage capacity for their chosen retention.
• For customer-controlled backup storage: maintaining valid credentials, sufficient capacity, and bucket-level encryption at rest.
• Periodically verifying that backups are restorable (we recommend quarterly).
• Promptly approving or applying Odoo updates, module updates, or security changes that require customer action or consent.
• For customer-provided cloud infrastructure deployments: maintaining a valid account, sufficient quota, and an active billing relationship with the chosen provider.
• Modifications made via SSH access — including the installation of additional or alternative software (e.g., alternative web servers, custom daemons, system packages), modifications to system or operating system configuration, or changes to the default Cloudpepper configuration. Any resulting instability, downtime, or security exposure is the customer’s responsibility.
• Verifying compatibility, security, and stability of custom or third-party Odoo modules before deploying them to production.
• Reporting incidents through the correct channel: My Cloudpepper > Support > “I have an incident” for P1/P2 (with critical impact and on-call paging selected for 24/7 response); support@cloudpepper.io or in-app chat for P3/P4.
• Submitting support requests with sufficient information to enable diagnosis (instance identifier, timestamps, error messages, reproduction steps).
• Maintaining secure credentials, applying multi-factor authentication where available, and managing user permissions for the hosted Odoo environment.

The cloud infrastructure underlying our High Performance and Dedicated Performance tiers, and our Managed Backup Storage, is operated by third-party sub-processors. A current list of sub-processors, including the entity, role, and processing region, is available in our GDPR & Data Processing Agreement.

This SLA is incorporated into and forms part of the Customer Terms of Service. Service credits described above are the Customer’s sole and exclusive remedy for any failure to meet the applicable availability objective and do not modify the exclusions or limitations of liability set out in the Customer Terms. This SLA is governed by Belgian law. Cloudpepper BV may update this SLA from time to time; material changes will be communicated to active customers at least 30 days in advance, and the version effective at the time of contract is the one that applies.