Service level agreement
Operational targets (pre-launch · indicative)
The numbers below are indicative of our current operational practice. They are not service-level commitments and do not give rise to service credits or other remedies. Specific availability, response, and recovery commitments applicable to a given customer are agreed in writing in the engagement and supersede anything stated here.
| Marketing site availability | Targeted high availability, with planned maintenance and force-majeure events excluded. |
|---|---|
| Platform availability (managed) | Targeted during pilot engagements. Single-region today; cross-region failover on the roadmap. |
| Severity-1 (full outage / data-loss risk) | Acknowledged promptly; continuous engineering work to resolution. |
| Severity-2 (degraded but usable) | Acknowledged promptly during business hours. |
| Severity-3 (minor) | Acknowledged in the ordinary course of support. |
Maintenance windows
We aim to schedule planned maintenance with reasonable advance notice, in windows that minimise disruption to customers in the operating regions we cover. Emergency maintenance is announced as soon as practical given the circumstances.
Status communication
A public status page is on the roadmap. Today, we communicate incidents directly to the customer's designated admin contact by email, and follow up with a written post-mortem for severity-1 incidents in a timely manner.
What's not covered
- Outages caused by the customer's own infrastructure (warehouse, IdP, network).
- Outages caused by upstream providers we depend on (model providers, CDN). We mitigate where possible and pass through what we know.
- Force majeure events.
At GA
The contractual SLA at GA will include service credits for missed availability, target response times by severity, and a clear scope of what counts as covered downtime. Larger deployments (VPC-isolated, on-prem) will have their own SLA, scoped to the deployment.
General: hello@jubi.my · Incidents involving security: security@jubi.my