OVHcloud: SLA evidence report

2026-09-22 to 2026-10-22 · read by RealUptime from our regions · generated Oct 22, 2026, 11:22 PM UTC

OVHcloud: SLA evidence report

Time our checks failed
4h
Across 3 probe events in this window.
Window
2026-09-22 to 2026-10-22
UTC, 30 days.
  • Sep 30, 2026, 8:48 PM UTC to Sep 30, 2026, 10:49 PM UTC

    Multiple regions: Europe, US-East, UK, Asia-Pacific, US-Central, Southeast Asia, Australia

    2h 1mchecks failing in this window

    OVHcloud's status page at the time: No claim history exists for this period

  • Sep 27, 2026, 12:52 PM UTC to Sep 27, 2026, 1:52 PM UTC

    Multiple regions: Europe, South America, US-East

    59.8mchecks failing in this window

    OVHcloud's status page at the time: No claim history exists for this period

  • Sep 27, 2026, 12:52 AM UTC to Sep 27, 2026, 1:51 AM UTC

    Multiple regions: Europe, South America

    59.2mchecks failing in this window

    OVHcloud's status page at the time: No claim history exists for this period

3 earlier probe events in this window happened before we began keeping a record of OVHcloud's own status-page claims, so no claim comparison exists for them.

What we check

primary
https://api.ovh.com/1.0/dedicated/server
secondary
https://www.ovhcloud.com/en/

Estimate an SLA credit from our check readings

Enter what you pay OVHcloud for this period and their own stated SLA target. This estimates a credit from the time our checks failed, shown above. The figure is an estimate from our checks andOVHcloud decides what counts. It is one common way to reason about an SLA credit, notOVHcloud's own contract terms, and it is not a legal determination. RealUptime is not counsel.

Based on 239.8 minutes with our checks failing across this report's window.

Methodology

Every event above is a period in which our checks of OVHcloud failed from two or more distant regions, meaning regions on different continents (see how we tell the difference). One that nothing else backs stops counting as an outage after 6 hours, and an event that fails these rules is retracted, kept, and listed on the corrections page. The time our checks failed is the wall-clock time inside the window an event's regions were failing; regions failing together still count as one event, not one per region. It is not proof of downtime for your account.

These figures come from our own checks of one public endpoint per service. They are not the service's real uptime.

OVHcloud's claim at the time comes from their own public status feed, polled on our own schedule, and is shown separately from our check readings. We never change our own reading based on what a vendor claims, and their claim never becomes our reading.

This is one external reading from RealUptime's own regions, not OVHcloud's own SLA measurement, which is usually defined against their own instrumentation and may cover a different scope than what we check. The credit estimate above is an estimate from our checks, and OVHcloud decides what counts. It is a starting point for a conversation with OVHcloud, not a legal determination, and RealUptime is not counsel.