Trust & reliability

Our reliability posture

alawadi.cloud is an Arabic-first managed cloud platform for the Middle East. The live UAE region runs on infrastructure we operate, and our approach to reliability is simple: publish the boundaries and back commitments with evidence rather than a number we cannot honor.

The UAE region uses a three-node cluster, which reduces machine-level risk and lets platform components reschedule after a node failure. It does not make every customer workload highly available: a single-replica app or database can still be interrupted while it recovers. On top of that, we make a real promise:

• A 99.9% monthly uptime SLA. We commit to it, measure it in public, and put service credits behind it. See the full Service Level Agreement.
• Automatic service credits — no claim required. If a month falls below 99.9%, we credit your prepaid balance for you: 10% below 99.9%, 25% below 99%, 50% below 95%. Most providers make you spot the outage and file a claim before a deadline; we made it an engine instead.
• We show the real measured number, even when it's unflattering. Our public measurement is young, so the live figure can sit below the target right now — and that is exactly when the automatic credit protects you.

The contractual terms always live in the SLA and the Terms of Service; this page explains how it works and never overrides them.

What the SLA covers

The 99.9% commitment is about availability — the platform's ability to serve your portal, the API, and the runtime behind your containers and managed databases. Some honest boundaries:

• AI inference is best-effort, not under the uptime SLA. It is served with published rate limits; requests may queue or return 429 under load, and a model swap or restart is a planned interruption.
• Backup and recovery coverage is service-specific. PostgreSQL and MySQL expose on-demand backups and point-in-time restore to a new instance. Redis (Valkey) has no platform backup or PITR today; its persistence option is not a substitute for an independent backup. We do not publish one blanket RPO or RTO across these engines. Keep tested independent copies of critical data.
• Single site. Three nodes survive a machine failure, but they share one site; a site-level event (power, connectivity) is what caps a single-site commitment at three nines. The SLA's exclusions name these honestly.

How we measure

A promise is only as good as the measurement behind it. Each signal is recorded, not estimated:

• Platform availability (the SLA signal): independent monitoring checks the platform every minute on the same public path your users take — your domain, the network edge, and routing — so we measure customer-perceived uptime. Each day's result is written to a durable daily availability ledger, the same record the automatic credits are computed from, published at api.alawadi.cloud/v1/public/sla-status.
• API availability & latency: the share of API requests that don't return a server error (5xx), and how fast requests complete.
• Managed databases: provisioning and connection health, plus backup and restore operation status for PostgreSQL and MySQL where those features are supported.
• Custom domains: the time from "create" to "certificate active".

When a month drops below 99.9%, the qualifying downtime is already on record — measured, not argued — and the credit is applied to affected accounts automatically.

Where to watch — in public

Real numbers beat promises. Everything is open:

• Live status: status.alawadi.cloud — a live view of recent checks for every component, where incidents are posted. The durable record behind the monthly number is the daily availability ledger above.
• Trust & transparency: the trust page — the live uptime number, the SLA, and exactly how the automatic credit works.
• Updates channel: we post incidents, recoveries, and maintenance in the open — follow the link on the trust page.

If something looks wrong with your own app, open a support ticket from the portal with your project id and what you're seeing.