Suspensions
When a workspace or an environment is over a limit, its sites answer with a status page instead of your app. Your deployments, variables and domains stay as they were, and everything comes back once the reason is gone.
Status pages
| Page | HTTP status | Why | How it comes back |
|---|---|---|---|
| Monthly limit reached | 429 | Free: the workspace reached its monthly requests. | Next month, or a paid plan. |
| Spending limit reached | 402 | Paid: the month's overage reached the spend limit. | Raise the limit, or wait for next month. |
| Site unavailable | 503 | The environment is past what the plan includes, usually after a plan change. | A plan that includes it. |
| Site paused | 503 | Free: nobody visited or deployed it for a while. | Deploy to it again. See Pausing & hibernation. |
| Waking up… | 503 | Paid: the environment was hibernated. | On its own, within seconds. |
Status pages are never cached, so visitors see your app again as soon as it's back.
Workspace suspensions
The first two apply to the whole workspace: every site in it shows the page. They're checked every 15 minutes, and lifted on the next check once the reason is gone. A plan change or a raised spend limit lifts them immediately.
The owner and admins get an email when one starts.
Over a plan's amounts
On Free, when a workspace has more than its plan includes (after a downgrade, for instance), the oldest keep running and the rest show Site unavailable:
- in each project,
productionfirst, then the oldest environments, up to the plan's environments per project; - across projects, the oldest projects' environments, up to the plan's live environments;
- the oldest custom domains, up to the plan's custom domains.
A new deployment never takes another site off the air: it's refused at build start instead.