The server

The start stops at "Database upgrade step … failed"

Every start brings the database up to date before anything is served, and a step that fails stops the start, so the server never serves a half-upgraded database. The message after the step's name says why: the database cannot be reached, its user may not change tables, the disk is full. Fix that and start again; the step runs again. Server health › Schema shows the record. See The database.

The server refuses to start because of its data keys

With encryption at rest on, every start checks that the configured keys open what was sealed before, and refuses to start if they do not, so data never ends up under two keys. Usually a key was mistyped, or an old key was dropped too early during a rotation. Put back the key that sealed the data: without it, sealed data cannot be read by anyone. See Keys and secrets.

Forms and submissions vanished after an update

On a container host, a storage root inside the container is wiped on every redeploy, and on some hosts at every wake from sleep. That is the storage, not the update. Mount a volume and point the storage root at it. The engine logs a DATA LOSS RISK warning at startup when it detects this in production, and Server health reports it. See The storage root. What was on the container's disk can only come back from a backup kept elsewhere.

Phones see a different server after a restart

Phones recognise a server by an identity derived from its secret key. A server started with a new SECRET_KEY is a different server to them; it also signs everyone out and can no longer read any garbling key sealed under the old one. Set the key once and keep it. See Keys and secrets.

Server health › Backups is red

The last backup failed or was refused, and the row says why. "Not enough room" means writing it would have left less than the reserved share of the disk free (20%, and at least 1 GB, by default): free some space, write backups to another disk, or keep fewer. A failed copy to the second disk shows amber. See Backups and restore.

A phone was told "received", but the submission is not in the console

The server answers a phone only once the submission is stored on disk; indexing it comes after. If indexing failed, the file is still there, and at every start the engine indexes anything on disk that the database does not know. Restart the engine and look again. Server health counts the submissions on disk that are not in the index.

The console says "not found" for something that exists

Something of another organisation, or of a workspace you are not assigned to while restricted workspaces are on, is answered as not found rather than forbidden, so its existence is never confirmed. Ask an owner to check your workspaces under People. Server administration (/admin) is not found for everyone but the server's maintainers, organisation owners included.

Everything is slow on a laptop server

An engine folder or storage root inside a folder that a cloud drive synchronises competes with the synchronisation for every file it reads. Keep the engine and the storage root on a local or dedicated drive, outside synchronised folders.