Service Level Agreement

Availability, backup, recovery, and support commitments for Odoo instances 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.

For the purposes of this SLA, “Availability” means the ability of the managed Odoo instance to be reachable over HTTP(S) and served by the Cloudpepper-managed infrastructure stack, as measured by Cloudpepper monitoring from external probe locations. Availability does not include application-level errors, performance issues, or outages caused by customer code, custom or third-party modules, customer data, customer-installed software, configuration changes, DNS issues, or third-party integrations. Events falling within the Exclusions section below do not count toward downtime.

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.

Cloudpepper-provided infrastructure runs 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.

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. This configuration is sometimes referred to as “Bring Your Own Cloud”. 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. Hardware characteristics, data center quality, and regional redundancy are determined by your chosen provider and the region you select.

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 Cloudpepper-Provided Infrastructure section above do not apply to customer-provided infrastructure deployments — infrastructure availability is governed by your chosen provider’s SLA.

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.

Severity Tiers and Response Times

Severity	Definition	Initial response	Coverage
P1 — Critical	Production instance unavailable, or platform-level data integrity issue (e.g., database corruption, backup integrity failure, restore capability impaired)	1 business hour	Business hours (Brussels time)
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

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.

Reporting Channels

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.
• P3 and P4 questions and general troubleshooting — support@oldv2.cloudpepper.io or in-app chat. These channels are not monitored 24/7 and are not appropriate for time-critical incidents.

24/7 Critical Response

Premium 24/7 response with on-call engineering paging and a 30-minute initial response target for P1 incidents is available as part of custom enterprise support arrangements. Contact sales to discuss requirements.

Engagement Throughout an Incident

Cloudpepper commits to active engagement and clear status updates throughout the incident lifecycle. Resolution times vary with the complexity of each incident and are not subject to a fixed commitment. Support is provided in English, French, Dutch and Spanish.

Shared Responsibility

Cloudpepper operates a shared-responsibility model. Cloudpepper is responsible for the Cloudpepper management platform, deployment automation and monitoring, the operating system and runtime environment, execution of backups per your configured schedule, and — for instances on Cloudpepper-provided infrastructure — the underlying infrastructure itself. The customer is responsible for custom and third-party Odoo modules, business data and its application-level correctness, integrations and DNS configured by the customer, modifications made via SSH access, credentials and user permissions on the hosted instance, and — for customer-provided infrastructure deployments — maintaining a valid account and quota with the chosen cloud provider. Issues falling on the customer side of this boundary are outside the scope of standard support and may be addressed through professional services.

Operational Access

Response time SLAs assume Cloudpepper retains operational access to the affected instance and its underlying infrastructure. Where access is impaired due to customer-side changes (e.g., firewall or SSH configuration), third-party provider outages, network or DNS conditions, or other factors outside Cloudpepper’s control, response time clocks are paused until access is restored. Cloudpepper will continue to assist with diagnosis and provider escalation on a best-effort basis during such periods.

Scope and Reclassification

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.

Data integrity scope. P1 data integrity coverage applies to platform-level data issues — including database corruption arising from infrastructure failure, backup integrity, and restore capability. Investigation of application-level data issues — such as incorrect values produced by customer code or modules, business logic errors, query performance against customer customisations, or recovery of user-deleted records outside of backup restoration — is outside the scope of standard support and may be offered as professional services.

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.

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@oldv2.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; support@oldv2.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 instance.

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.