Documented case study · Evidence through 30 October 2026
On 23 October, two OVHcloud virtual private servers in Zurich were running and showed automatic monthly renewal. On 30 October, both were still listed in the account, but their status had changed to expired and stopped. Automatic renewal remained enabled, and the recorded expiration date was still 23 October.[1]
Between those observations sits a business problem: how should a customer act when the control panel says renewal is automatic, reminders demand manual renewal, and support points to a confirmation banner that explicitly excludes VPS services? The records show that contradiction. They do not establish why the renewal failed or whether a payment was attempted.[7]
This case study draws on records from the publisher’s technical advisory work. Customer and service identifiers are withheld, and the adviser’s decisions are examined alongside the provider’s response. The implications concern any business planning around hosted infrastructure; the evidence describes this account, not OVHcloud’s performance as a whole.
Planning a hosting review? Discuss server continuity, renewal checks and recovery planning with our engineering team.
An earlier server had already disappeared
The account’s earlier Zurich VPS was a separate service. By 2 October, it was absent from the account’s server list, and a contemporaneous record preserved the user’s confirmation that it had been deleted. Later requests through OVHcloud’s application programming interface, or API, returned a service-not-found response.[2]
Its renewal history matters. A saved API response from 10 September showed manual renewal and an expiration date of 20 September. A reminder forwarded on 17 September listed that server and its options for manual renewal. When the customer asked whether another approval was needed, the adviser replied that the arrangements should already be in order and promised another check.[3]
OVHcloud subsequently said automatic renewal had not been fully configured for this earlier service. The September setting supports the manual-renewal part of that explanation. It does not establish the exact deletion time, the initiating person or automated process, or whether data was permanently lost. The reviewed material contains no deletion audit trail resolving those questions.[2][7]
A separate September support case concerned QXL virtual graphics errors and a subsequently documented reboot delay. The initial report said no application performance impact had been observed. OVHcloud requested diagnostic tests; the records preserve a detailed customer response but do not demonstrate completion of every requested test. That history does not establish a cause for the later disappearance or expirations.[4]
The later servers had a different renewal record
The two later Zurich VPS initially appeared with manual renewal in an early 2 October capture. Following a reported settings change, another check that day confirmed automatic monthly renewal. Further checks on 8, 20 and 23 October recorded the same configuration.[5]
The API showed automatic renewal enabled, a one-month renewal period, manual payment disabled and deletion at expiration disabled. On 23 October, both servers were running with an OK service status. A screenshot supplied that day also showed them as active, with automatic renewal every month.[1]
Those checks provide strong evidence of the configured settings. They do not show that the next invoice had been settled or the service term extended. The account had a default payment method and an earlier overview of paid invoices, but neither established payment for the approaching Zurich renewal.[6]
The control panel’s “No commitment” label appeared alongside automatic renewal. It did not mean that automatic renewal was disabled. Equally, a customer-applied “LIVE” label does not establish what workloads were running, whether a public website became unavailable or whether revenue was affected.[1]
Support replied, but the required action remained unclear
A support request opened on 8 October asked OVHcloud to confirm automatic renewal and payment, identify any further action required, and explain the earlier server’s disappearance. It explicitly did not authorise cancellation or deletion. The first visible human reply in that ticket is dated 23 October: an interval of approximately 15 calendar days.[7]
The reply apologised for the delay. It said the earlier server had not been fully configured for automatic renewal. For the other VPS, support said automatic renewal was initiated but still needed confirmation in the red area of the billing page.[7]
However, the red banner visible in the screenshot supplied on 23 October began: “This message does not apply to Bare Metal and VPS services.” The rest of the banner referred to an automatic-renewal option that had not yet been authorised.[1] A customer following the reply therefore faced an instruction apparently directed at a warning that excluded the product concerned.
The record does not show what that confirmation would have changed behind the scenes. It does show why the reply was insufficiently specific: it did not reconcile the VPS exclusion with the action requested or identify a payment attempt that had failed.
A second ticket, opened on 21 October about the contradiction between reminders and settings, was closed on 23 October as a duplicate of the first. Closing duplicate cases is not, by itself, evidence of poor handling. Here, it directed the customer back to the same answer without resolving the contradiction. The original ticket later received an automated completion follow-up; the customer disputed the answer and requested restoration on 30 October.[8][7]
The reminders concerned the servers themselves
The renewal notices covered the servers themselves, as well as optional extras. The messages dated 23 and 24 October named both base Zurich VPS as well as their snapshot and storage options under manual renewal. The 24 October notice continued to show 23 October expiration dates under a heading describing services expiring that day.[9]
These notices were warnings, so it would be inaccurate to say the customer received none. The problem was their inconsistency with the saved renewal settings. The account records did not give the customer a clear explanation of which information should determine the next action.
The adviser’s reassurance forms part of that decision history. On 20 October, the adviser confirmed the automatic settings and said they did not need activating again, while acknowledging the unexplained reminder. On 23 October, a sent email again confirmed that the servers were running and automatic renewal was enabled, described the emails as probably misleading, and promised a recheck on 24 October.[10]
No completed 24 October recheck was located in the reviewed evidence. That does not prove no check occurred. The reassurance rested on verified settings; a settled payment and an extended service term remained unconfirmed.[10]
Expired and stopped, with automatic renewal still enabled
On 30 October, the customer’s screenshots showed both later services as expired while retaining the automatic-renewal label. The API recorded both VPS as stopped, their service status as expired, and the same 23 October expiration date. It still recorded automatic renewal with a one-month period.[1]
There was another display detail: beneath “Automatic,” the later dashboard showed no renewal frequency, whereas the earlier screenshot had shown “Every month.” The API’s one-month setting persisted. This is another difference to explain, not proof of a particular billing fault.[1]
The customer reported that attempting to change status produced an expired-service error; the attached error image does not identify which server was selected. Related API requests also returned expired-service errors. Both VPS remained listed at the final check.[11] Their continued presence in the account distinguishes these expirations from the earlier disappearance. No deletion of the two later VPS was established. The observations do not pinpoint when they stopped or establish continuous downtime, lost data or customer-facing disruption.
What a business needs to be able to rely on
OVHcloud’s public renewal guidance distinguishes automatic from manual renewal and explains the role of a registered payment method. Its billing guidance also recognises suspension where payment is not settled. Those distinctions reinforce the need to separate a renewal setting from a completed billing event; they do not explain what happened in this account.[12]
The unresolved questions are concrete. Was a renewal invoice generated? Was a payment attempted, and with what result? Why did manual-renewal notices include services configured for automatic renewal? Which confirmation did support mean, given the banner’s VPS exclusion? For the earlier server, what event led to its removal, and what recovery options remained?
For business planning, reliable hosting administration means those questions have actionable answers before a deadline. A customer needs to know who must act, what must be done and how completion will be confirmed. A clear renewal status, an advanced service term and a traceable payment outcome offer more assurance than a setting alone.
This case also shows why advisers need to distinguish a configuration check from a completed renewal check and record promised follow-ups. The evidence supports criticism of conflicting information and an unresolved support exchange. It does not establish the underlying failure mechanism or justify a general verdict on OVHcloud’s Zurich operations.
We value OVHcloud’s products and regard the company as a capable provider. Our concerns about this Zurich case sit alongside that positive assessment. The records leave practical questions unresolved: how automatic renewal translates into continued service, what confirmation a customer must provide, and how support communicates the action required. These are matters that need clarification and, where shortcomings are confirmed, improvement. Businesses need to be able to turn the information in their account into dependable operational decisions.
The practical concern remains: a business cannot plan confidently around a server when the available information leaves it uncertain whether keeping that server requires further action. Resolving that uncertainty is part of providing a dependable service.
Reviewing your own hosting arrangements? Talk to our engineering team about dependencies, renewal responsibilities and recovery planning.
Source notes
Private account records and correspondence were reviewed through 30 October 2026. The originals are retained privately; these notes describe their evidential role without publishing identifying details. Historical ticket and notice pages were captured on 30 October, not on their message dates. Exact capture times for customer-supplied screenshots are unknown. This is a review of the supplied records, not a complete audit of the provider’s systems or all customer communications.
- Before and after. Saved API responses and a screenshot supplied on 23 October; customer screenshots received on 30 October; final API check on 30 October. Running/OK became stopped/expired; automatic renewal and the expiration date persisted. The earlier screenshot also preserves the banner wording and commitment labels.
- Earlier disappearance. Server inventory from 2 October, contemporaneous user-confirmed deletion record, and service-not-found API responses on 8 and 30 October. The cause and exact deletion time are unverified.
- Earlier renewal setting and advice. API response dated 10 September; forwarded manual-renewal reminder and adviser’s reply dated 17 September.
- Separate technical case. September performance-ticket transcript and preserved diagnostics, including the initial report and subsequent reboot-delay report. No established connection to renewal or deletion.
- Renewal checks. Initial and follow-up API captures on 2 October, repeat captures on 8 October, a recovered API summary from 20 October, and raw responses from 23 October. The original full 20 October API file was unavailable.
- Payment evidence limit. Account-interface observation and support request dated 8 October. A saved default payment method and earlier paid invoices do not demonstrate settlement of the later renewal.
- First renewal ticket. Opening request on 8 October; first visible human reply on 23 October; system follow-up on 26 October; customer dispute and restoration request on 30 October. Displayed ticket timezones are unverified.
- Duplicate closure. Second ticket opened on 21 October, with a supporting attachment; closed on 23 October as a duplicate.
- Renewal reminders. Historical notices dated 23 and 24 October, including the base-server and option entries.
- Adviser’s reassurance. Sent emails dated 20 and 23 October; the latter promises a 24 October recheck. No completed recheck was located in the supplied material.
- Expired-service errors. Customer email and error attachment dated 30 October; same-day API responses and final server inventory. The error screenshot alone does not identify the selected VPS.
- Public provider context. OVHcloud, How to renew OVHcloud services and Billing and payment FAQ, consulted on 30 October 2026. General guidance, not an account-specific finding or determination of applicable contract terms.
