# SLA & Uptime

> Source: https://agilitycms.com/docs/owners-admins/sla-and-uptime

Agility distinguishes between two service levels: the **management/authoring layer** (Content Manager and Management API, used by editors and integrations) and the **delivery layer** (the content/asset APIs and edge/CDN that serve published content to end users). The architecture is designed so that end-user delivery availability is materially higher than any single API's standalone availability: because front ends built on Agility are typically statically generated and content is distributed to the edge, **already-published content keeps serving even when the origin/management layer is briefly unavailable.** This decoupling is how an Agility-powered site can achieve effective five-nines (99.999%) end-user availability even though no single content API is contractually guaranteed at 99.999% in isolation.

## Two SLAs, two purposes

| Service level | Covers | Who depends on it | Sensitivity to brief interruptions |
| --- | --- | --- | --- |
| **Delivery SLA** | Content Fetch / GraphQL APIs and edge/CDN serving published content | End users of the live website/app | Low — edge/static caching absorbs brief origin events |
| **Management SLA** | Content Manager UI and Management API (authoring, publishing, integrations) | Editors, integrations, automation | Higher — affects authoring, not necessarily live delivery |

Both service levels have defined availability targets, which are **contracted as part of each customer's agreement with Agility**. **For the current SLA figures and service-level terms, [contact Agility](https://agilitycms.com/contact-agility-cms)** — they are provided directly as part of the contract or an RFP/procurement review, rather than published here.

![Request path with hosted/static fallback: a request normally serves a pre-rendered page instantly; during a hosting or infrastructure issue the cached and statically generated layers still serve the last-good page, while Agility's content API stays healthy and is fetched only for fresh content — the path to the user stays green.](https://cdn.aglty.io/agility-cms-docs/images/owners-admins/diagram-edge-fallback.svg)

## Why effective end-user availability exceeds a single API's SLA

The five-nines claim is an **architecture** outcome, not a single-component guarantee. It rests on layered fallback in the request path:

1. **Static generation / pre-rendering.** Most production sites pre-render pages at build time, so end users are served HTML that does not depend on a live API call per request.
2. **Edge/CDN caching.** Published content and assets are cached at edge locations close to users. A cache hit is served entirely from the edge, independent of origin health.
3. **Stale-while-revalidate / cached fallback.** During a brief origin or API event, the edge can continue serving the last-good cached response while it revalidates, so end users see no interruption.
4. **Independent layers.** A management-layer incident (authoring/publishing) does not stop the edge from serving already-published content.

The practical result: the probability that an *end user* cannot load published content is far lower than the availability of any one upstream API, because multiple independent layers must fail simultaneously to produce user-visible downtime.

**Five-nines is an architectural outcome, not a contractual guarantee.** It describes what a correctly implemented static/edge front end achieves in practice. The contractual availability targets are a separate matter — defined in the Customer Agreement and available on request ([contact Agility](https://agilitycms.com/contact-agility-cms)).

## Maintenance windows

Scheduled maintenance and its treatment under the SLA are governed by the Customer Agreement. Because the management layer is decoupled from delivery, maintenance on authoring/management services generally does not interrupt live end-user delivery of already-published content. Maintenance-window notice periods and SLA-exclusion treatment are available on request — [contact Agility](https://agilitycms.com/contact-agility-cms).

## Service credits

Service-level credits, the claim process, measurement window, and exclusions are defined in the Agility Customer Agreement. The service-credit schedule and claim terms are provided as part of the agreement rather than published here; [contact Agility](https://agilitycms.com/contact-agility-cms) for details.

## Status and monitoring

Agility publishes live platform status and incident history at **[status.agilitycms.com](https://status.agilitycms.com)**, where customers can also subscribe to incident notifications.

## Shared responsibilities

| Area | Agility | Implementation partner / customer |
| --- | --- | --- |
| Platform delivery & management SLAs | ✅ Meets stated availability targets; publishes status | Monitors against its own requirements; claims credits per agreement |
| Edge/CDN delivery of published content | ✅ Operates platform edge layer | — |
| Achieving five-nines *end-user* availability | ✅ Provides static/edge-friendly APIs and caching | ✅ Implements static generation, correct cache/revalidate config, and (optionally) its own front-end CDN with fallback |
| Front-end app uptime | — | ✅ Owns the availability of its own website/app and hosting |
| Maintenance coordination | ✅ Schedules and notifies | ✅ Plans editorial/release activity around notified windows |