Service Levels and Backups
Last updated: September 2, 2026 · Version 1.0
Courtesy translation. The Spanish version published at bimxcloud.com/legal/niveles-de-servicio is the only binding version. If the two differ, the Spanish text prevails.
This document forms part of BIMXcloud's Terms and Conditions of Service and sets out what is committed in relation to support, provisioning, backups and restoration. Capitalised terms have the meaning given in section 2 of the Terms.
What is published here is what the operation delivers today. Where something is not committed, we say why.
1. What this document covers
In short: the part we administer. Your network, your equipment and your licences are not included.
It covers the dedicated Instance that BIMXcloud provisions, hosts, administers and backs up, and the services it runs according to the contracted plan: Revit Server, ERPNext and Nextcloud.
It does not cover the Customer's internet connection, local equipment or internal network, software the Customer installs on its own inside the Instance, or the licensing of the programs it runs on it.
2. Support
In short: 08:00 to 22:00, Monterrey time, every day. The people who answer are the people who administer the servers.
2.1 Hours. From 08:00 to 22:00, Monterrey time (GMT-6), every day of the year, including Saturdays, Sundays and public holidays.
2.2 Channels. Email to support@bimxcloud.com and WhatsApp. Current contact details for each channel are published at bimxcloud.com. Requests received outside these hours are handled from 08:00 the following day.
2.3 Response time. We do not publish a committed response time. Support is provided by the same team that administers the servers, which makes the answers technical and direct, but also means we cannot today guarantee a first-response time that holds in every case. We would rather not commit to a figure we cannot always meet. What is committed is the restoration time in section 4.
2.4 Scope of support. It covers the operation of the Instance and the managed services: access, performance, updates, user configuration and recovery. It does not include training in the use of Revit, ERPNext or Nextcloud, nor the firm's own functional configuration — templates, workflows, catalogues, reports, data migration. That work is quoted separately.
2.5 Languages. Spanish and English.
3. Backups
In short: one daily backup of the complete server, on separate infrastructure, with a single restore point: the most recent one.
3.1 What is backed up. The complete server, not individual files: system, configuration, databases and content.
3.2 When it runs. Once a day, between 00:00 and 01:00, Monterrey time. We publish the window because how much work can be lost depends on it: a failure at 22:00 returns you to that same early-morning backup, that is, a day's work. See §4.3.
3.3 Where it is kept. On infrastructure independent of the Customer's Instance, so that a failure of the server does not take the backup with it.
3.4 How many versions. One. The backup keeps only the most recent state and is overwritten with each daily run. There are no historical backups of earlier days. If a problem is discovered three days after it occurred, the backup already contains it: there is nowhere to go back to.
3.5 Retention after deletion. When an Instance is deleted, we keep the backup of the last active day for up to 30 calendar days, in accordance with section 7.5 of the Terms. After that period the information is erased irreversibly.
3.6 History inside the Instance. Independently of the backup, each product keeps its own history inside the Customer's Instance:
| Product | What it keeps |
|---|---|
| Revit Server | A restore point for each model synchronisation, allowing a return to an earlier version. |
| Nextcloud | File versions and recycle bin, according to the product's configuration. |
| ERPNext | Change history per document. |
This history is the first tool for a user error — a badly synchronised model, a file deleted by mistake — and does not depend on the daily backup. It lives inside the same Instance, so it does not protect against failure of the server; that is what the backup is for.
3.7 The Customer's own backups. The Customer may keep its own copies outside the Service and we recommend doing so for critical project information. The backup we include is designed to recover the server, not to replace the firm's archiving policy.
4. Restoration after a failure
In short: we restore within 4 hours of you telling us, within support hours, at no cost. But restoration takes you back to yesterday's backup: you can lose up to a day's work.
4.1 The commitment. Where a failure prevents use of the Instance and is reported to us, we restore the server from the most recent backup within 4 hours.
4.2 How the clock runs. The clock runs only within support hours (08:00 to 22:00, Monterrey time). If the report is received within those hours, it starts immediately. If received outside them, it starts at 08:00 the following day. This is the same criterion that applies to provisioning.
4.3 What can be lost. Read together with the above: restoration returns the server to the state of the last daily backup, so up to 24 hours of work can be lost. The 4 hours are how long we take to restore. The 24 hours are the work that can be lost. They are not the same figure and should not be read as if they were.
4.4 No cost and no argument about fault. Restoration is always at no cost, regardless of the cause of the failure, including where it arises from use of the Instance by the Customer, its users or its collaborators, or from malicious software introduced through their access. We do not make restoration conditional on establishing whose fault it was.
4.5 When the time limit does not apply. The 4-hour commitment assumes the backup is available and that there is infrastructure to restore to. It does not apply where the cause is a widespread failure of the infrastructure provider or of an entire data centre, a force majeure event under section 20 of the Terms, or an inability to access the Instance for reasons attributable to the Customer. In those cases we restore as soon as materially possible and keep you informed of progress.
4.6 Remedy and liability. The restoration described here is the remedy provided in section 17.1 of the Terms. This document creates no service credits or additional compensation: BIMXcloud's financial liability is governed exclusively by section 17 of the Terms.
5. Provisioning
In short: normally an hour; up to four at the weekend; if you order overnight, we start at 08:00.
| When the order is received | Target time |
|---|---|
| Business day, within support hours | Approximately 1 hour |
| Saturday, Sunday or public holiday | Up to 4 hours |
| Outside support hours | Starts at 08:00 the following day |
Times run from when we receive payment and the Customer's information in full. Business day means Monday to Friday, excluding Saturdays, Sundays and public holidays in Mexico and the United States.
These are target times based on actual operations, not commitments backed by penalties. If provisioning is significantly delayed we will tell you, and you may cancel with a full refund.
6. Availability
In short: we do not publish an availability percentage, and we would rather explain why than invent one.
6.1 No committed percentage. BIMXcloud does not publish a guaranteed availability percentage. This is not an oversight: we do not yet have twelve months of continuous monitoring data that would let us commit to a figure we can stand behind and evidence. Publishing a "99.9%" with no data behind it would be a statement we could not defend against a customer who invoked it.
6.2 What we do offer in the meantime. Dedicated instances with no resources shared with other customers, a daily backup on independent infrastructure, the restoration commitment in section 4, and support for 14 hours a day, 365 days a year.
6.3 When we have the data. Once monitoring has accumulated a sufficient period, we will assess publishing a figure. If we do, it will be in this same document and with the notice appropriate to a substantial change.
7. Maintenance
In short: scheduled maintenance is announced; security maintenance may be immediate.
7.1 Scheduled. Notified by email with reasonable advance notice and arranged outside the Customer's working hours where possible.
7.2 Emergency. Security maintenance — critical patches, containment of a vulnerability — may be applied immediately, with notice afterwards as soon as possible.
7.3 Product updates. Updates to Revit Server, ERPNext and Nextcloud are coordinated with the Customer where they involve visible functional changes, and applied directly where they are corrective or security-related.
7.4 Maintenance windows and availability. Scheduled and announced maintenance is not treated as a failure of the Service.
8. Exclusions
What is provided in this document does not apply where unavailability or loss of information arises from:
8.1 The Customer's internet connection, internal network or equipment.
8.2 Software installed or configuration changes made by the Customer or its users inside the Instance, where these prevent start-up or access.
8.3 The licensing of the Customer's software or its suspension by that software's vendor.
8.4 Force majeure or unforeseeable circumstances under section 20 of the Terms, including widespread failure of the infrastructure provider.
8.5 Suspension for non-payment (section 7 of the Terms) or for breach of the Acceptable Use Policy.
In cases 8.1 to 8.3 we continue to help within support hours: what does not apply is the committed restoration time, not the assistance.
9. Changes to this document
Changes are published on this page with their update date. Substantial changes are notified by email 30 calendar days in advance and take effect at the next renewal, as with changes to the Terms.
10. Contact
support@bimxcloud.com — failure reports, restoration requests and maintenance notices.