SLA & 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 — they are provided directly as part of the contract or an RFP/procurement review, rather than published here.

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).

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.

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 for details.

Status and monitoring

Agility publishes live platform status and incident history at 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