Service Level Agreement

1. Availability commitment

We commit to a Monthly Availability of at least 99.9% for the core platform — the customer portal, the control-plane API, and the runtime that keeps your deployed containers and managed databases serving. At 99.9%, total unplanned downtime across a 30-day month is about 43 minutes.

This SLA covers availability — the platform's ability to serve your workloads. Data durability is addressed separately in section 6.

2. How we measure availability

Monthly Availability = (total minutes in the month − Downtime minutes) ÷ total minutes in the month, expressed as a percentage.

"Downtime" means a period in which the core platform fails automated health checks for two (2) or more consecutive minutes, measured by independent monitoring against the same public path your users take (your domain → the network edge → the platform). Downtime ends when the checks recover. Isolated single-check failures within an otherwise-healthy period are not counted.

Our public status page provides a live view of recent health checks for every customer-facing component. The authoritative record of availability is the durable daily availability ledger, published at api.alawadi.cloud/v1/public/sla-status, which is the same data service credits are computed from. You do not have to take our word for it; both are open for you to inspect.

Automated monitoring measures the customer portal and the control-plane API over the same public path customers use. If an interruption affects an individual workload without being captured by this platform-level monitoring, report it under section 4 within thirty (30) days so it can be corroborated and included.

3. Service credits

If Monthly Availability for a calendar month falls below the 99.9% target, we automatically apply a service credit calculated as a percentage of the charges for the affected resources in that month:

Below the 99.9% target: 10% credit. Below 99.0%: 25% credit. Below 95.0%: 50% credit.

Only the single highest applicable credit applies for a given month; credits do not stack. "Affected resources" means the core-platform resources — container compute and managed databases, plus the storage attached to them — that were rendered unavailable by the qualifying Downtime; it excludes the private registry, custom hostnames, AI inference, and any resource that remained reachable.

Credits are applied as prepaid balance credit, consistent with our prepaid, pay-as-you-go model — there is no cash refund, and SLA credits are not redeemable for cash even after they are applied to your balance. Credits are capped at your total charges for the affected resources in the affected month, and are your sole and exclusive remedy for any failure to meet this SLA.

4. Automatic credits and missing downtime

After each calendar month closes, our credit engine evaluates the durable availability ledger and automatically applies the highest credit due to affected prepaid accounts. You do not need to detect the breach, contact support, or file a claim for Downtime captured by our monitoring.

If an interruption affecting your workload was not captured by platform-level monitoring, contact [email protected] from your account email within thirty (30) days after the end of the affected month. Include your account identifier and the approximate dates and times of the interruption. This reporting window is a safety net for missing measurements, not a prerequisite for automatic credits.

Our monitoring records are the authoritative measurement of availability. Where our monitoring under-records an interruption that you can independently evidence, we will calculate the credit using the corroborated interruption. A given incident gives rise to at most one credit, the credit for a month may not exceed the cap in section 3, and reports submitted after the 30-day window are not eligible to adjust that month's calculation.

5. Exclusions

The following do not count as Downtime and are not eligible for credits: (a) scheduled maintenance announced in advance, and emergency maintenance required to protect security or stability; (b) problems caused by your own code, configuration, or content, or by exceeding your plan's quotas or prepaid balance; (c) factors outside our reasonable control, including upstream network, DNS, or content-delivery providers, your own network or device, and force-majeure events such as regional connectivity loss, power-grid failure, or natural disaster; (d) suspension or termination for non-payment or for breaches of the Terms or Acceptable Use Policy; (e) features explicitly labelled beta, preview, or experimental.

The AI inference API is provided on a best-effort basis with published rate limits and is not covered by this availability SLA.

6. Data durability and recovery

Backup and recovery coverage differs by service. Managed Postgres and MySQL include encrypted backup and point-in-time recovery controls; managed Redis and Basin object storage do not currently carry the same backup or PITR commitment. No platform-wide recovery-point objective applies to every customer resource. Keep independent copies of anything critical.

This SLA does not yet commit to a specific recovery-time objective (how quickly a restore completes). We will publish a recovery-time commitment once it is proven by tested restore drills. Until then, please keep your own copies of anything critical, as also stated in the Terms.

7. Changes to this SLA

We may update this SLA as the platform matures — for example, to tighten targets or to add a recovery-time commitment as our infrastructure grows. We will post the updated version with a new effective date, and material reductions will be communicated in advance.