Status page

Every App has a status page in the dashboard. It answers one question: is this site working.

Open an App and follow Status page in the header, or go straight to /apps/{app}/status.

The page is not a smaller version of the App page. It is built from a separate answer, so nothing you add to the App later shows up here by accident. It never carries your logs, your environment variable names, your usage figures, your plan, your deploy credentials, your schedules, or any other App in the workspace.

What it says

The site’s name, and whether it works. The page is titled with the App’s name. A dot sits before it: green when the site works, amber when something needs looking at, red when we took the site down, and faint when nothing has been published yet. Under the name is one sentence. On a working site it says Working normally.

What is wrong, if anything. When something is wrong, the sentence under the name says what, in plain words, and says what to do or expect. A word beside the name gives the problem a short name: Restricted, Paused, Failing, Not published, Address coming up or Address being removed. When all is well there is no word there. A domain waiting on DNS and a site somebody switched off read differently, because the next move is different.

Under that, one card holds three lines.

Address. The name to type to reach the site, as a link. That is your custom domain once it answers, and the wawesome address until then. A custom domain still coming up, or being taken off, is named under the address with where it has got to: Coming up or Being removed. A domain still coming up is waiting on a DNS record. Custom domains has the records and what each state means.

Last updated. The day of the most recent deploy into the App.

Recent errors. Nothing, a few, or a lot, over the last day. A count is not useful to somebody who cannot act on it, so there is not one. A 404 your handler returned is not a failure: that is your code saying the request was wrong. A day with only a handful of visits never reads as a lot: one failure out of two is not a pattern, and your own figures are where a single failure is worth looking at.

The page reads the status again every 30 seconds while it is open. If it cannot be read, the page says so and offers to try again.

The states you can meet

The page says	What it means
Nothing has been published yet	The App exists and no deploy has landed in it.
Switched off by whoever looks after it	Somebody paused the App. Nothing is deleted, and unpausing brings it back.
The platform has made this site unreachable	We took the site down. Only we can put it back, and the reason went to whoever runs the workspace.
The address does not answer yet	The custom domain is waiting on a record at the registrar.
The address is being taken off this site	The domain is being detached. The site keeps running at its wawesome address.
A lot of visits failed in the last day	The site answers, and much of what it answers is failing.

Paused is your own switch. Concepts has the rest of the vocabulary. A failed payment never stops a site serving, so it never appears here.

The figures, on your side of it

The status page carries no counts, because the person it is written for cannot act on one. You can, so your own side has them. Open the App in the dashboard and the Functions tab says what the last 24 hours held: how many requests came in, how many of them failed as both a count and a share, a p95 response time, and the data the App sent back out. Beneath them is one chart of requests against failures, hour by hour.

The hours are UTC, so the chart reads the same wherever you are. The figures are up to a minute old and the page says so. Deploying makes them current again.

An App too busy to count quickly still answers. The page falls back to the totals for its last complete day, drops the chart, and says which day the figures are from.

The Overview, for the whole workspace

The status page answers for one App. The dashboard’s home page answers for all of them: open the dashboard and you land on Overview, which says in one sentence whether anything in the workspace needs you.

It says one thing, the worst thing. A site the platform has taken down is said before a domain that is still coming up, because you cannot do anything about the first and the second can wait. When nothing is wrong it says so, naming the workspace it is about.

An app you paused yourself never changes that sentence. You switched it off, so nothing is wrong. The app’s own row is where it says it is off.

Under the sentence are three figures for the whole workspace over the last 24 hours, each with a small chart of the hours in it: how many requests you served, how many of them failed as a share and a count, and how long a response took at the 95th percentile.

Two of those are easy to misread, so the page says what each covers. The request count is visits, counted the way this page counts them. It is not the figure on your usage page, which is what you are billed for and leaves out failures on our side. The response time covers the runs that finished. A run that never answered is a failure rather than a slow one.

The same three figures sit on Applications and on an App’s own page, where they cover that one app instead of the whole workspace, and on a function’s Overview tab, where they cover that one function. Both warnings above hold on all four, and so does one more: the figures are up to a minute old, and a deploy makes them current again.

A function you paused still shows what it served before it stopped. When its app is too busy to count quickly, the function’s figures are blank, because the totals we keep for a closed day are kept per app. The app’s own page still has them.

The page reads them again every five minutes, and again the moment you come back to the tab, so one left open on a second screen is not showing you this morning. A tab you are not looking at asks for nothing.

Under the figures is one row per app, so you can see which app the trouble is in. Each row carries a state dot, the app, the address it answers at, what it served over the last 24 hours, how much of that failed, a small chart and the last deploy. The whole row is a link to the app.

The dot says whether the app is serving. The figures beside it say how much traffic it had. Those are two different things: an app that is working fine with nobody visiting keeps its green dot, shows 0 requests and a dash for failures. A quiet day is not a broken site.

The rows put trouble first and then sort by requests. An app that has stopped, or one whose visitors are meeting failures, is at the top even when nobody is visiting it. An app you paused yourself is not trouble, so it stays where its traffic puts it and carries a Paused chip. A custom domain still coming up, or on its way off, is marked beside the address it is about.

Last deploy is the most recent one across the whole app, and it names the function it went to. An app holding three functions has three live versions, so there is no one version number for the app itself.

Five apps show. All applications takes you to the full list at /apps, which holds the same rows.

A workspace too busy to count quickly still answers, the same way one app’s page does. The figures become the totals for your last complete day, the small charts go, and the page says which day it fell back to. The verdict and the app rows are still there, so you can still see whether anything needs you. The failure figures are blank on that day rather than zero: the totals we keep for a closed day count requests, not failures.

Under the rows is Recent deploys: what is live across the workspace, most recently deployed first. Each line carries the version, the app and function it answers at, the message you wrote with the deploy, and how long ago it went live. A workspace that has never deployed keeps the card, which says nothing is live yet.

The list holds one line per function, because it reads what is live right now rather than a history. Deploy the same function twice in a day and you see one line, carrying the version that is live. A rollback counts as a deploy: the function you rolled back moves to the top of the list, under the version you put back.

A read that fails says so. If we cannot tell you what the workspace holds, Overview and Applications say the workspace could not be read and ask you to try again in a moment. Neither page shows you an empty workspace instead. A page saying “nothing here” because a read failed would be wrong about the one thing you came to check.

Every app still has its own status page, and the full list of them is at /apps.

Showing it to whoever pays for the site

This is the page you can hand to a client. Inviting a client gives them an account that reaches this one page for one App, and nothing else in your workspace.