> ## Documentation Index
> Fetch the complete documentation index at: https://docs.modelence.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Availability

> Failovers and deploys

Modelence Cloud operates production services to a 99.9% uptime target. Real-time and historical
availability, and any ongoing incidents, are published at
[status.modelence.com](https://status.modelence.com).

## Containers

An environment's service runs as one or more containers on AWS Fargate, spread across two
availability zones in the environment's [region](/cloud/regions.md). Each container is checked every 30
seconds to confirm the app still accepts connections on its `PORT`, and a container that fails three
checks in a row is replaced.

Deploys and container replacements never take the app down: a new container is always started and
checked before the one it replaces is stopped. To also keep serving through an app crash or the loss
of a whole availability zone, run two or more containers, so the others handle traffic while one is
replaced. Each container is billed separately.

## Deploys

A deploy starts the new version's containers next to the running ones, and the old containers are
stopped only once the new ones are up and passing checks. If the new version keeps crashing, the
deploy is rolled back automatically and the previous version keeps serving, so a broken build never
replaces a working one.

## Databases

Managed databases store their data redundantly, so losing a single machine doesn't lose data. When
the machine serving a database fails, the database is brought back on a healthy one automatically,
which takes from a few seconds to a few minutes depending on the database, and most database clients
reconnect on their own once it's back.

Production databases are also [backed up](/cloud/backups.md) at least every six hours.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.