When things go wrong

The failures you are most likely to meet, what each one actually means, and what to do.

Ordered by how often they happen rather than by how serious they are.

My application will not start

Read the logs of the copy that failed, not of the application in general. Logs from copies that never became healthy are kept precisely for this.

In order of likelihood:

  1. A missing environment value. The application reads a setting at startup, does not find it, and exits. The log usually names it.
  2. Something it depends on is not reachable yet. A database ordered a minute ago may not have finished electing a primary. Retry the deployment.
  3. It listens on a different port from the one the platform was told, so it is running perfectly and nothing can reach it.
  4. It binds to localhost. Inside its own copy, localhost means only this copy. Bind to all interfaces.
  5. It is slow to start. The platform waits a generous but finite time for a new copy to answer. An application that runs migrations, warms a cache and builds an index before answering may exceed it. Answer first, do that work in the background.

The deployment failed but my site is still up

Working as intended. A new version that never answers does not replace the one that is serving. Read the failed deployment's logs; the running version is untouched.

The deployment succeeded but I still see the old version

Three possibilities, in order:

  • Your browser cached it. Try a private window before anything else.
  • A connection that was already open. Existing connections are allowed to finish rather than being cut mid-response. A client holding a long-lived connection keeps talking to the old copy until it reconnects.
  • Your own cache. If you put a cache in front of your application, it is serving what it was told to keep.

My custom domain does not work

See Addresses and domains for the full list. The short version:

  • It works for you and not a colleague → the change has not reached everyone yet. Wait.
  • Insecure loads, secure does not → the certificate is not issued yet, because the name has to resolve to the platform before it can be.
  • Nothing resolves at all → check the record actually exists, and that nothing else at your registrar overwrote it.

Your platform address always works. Use it to confirm the application itself is healthy before spending time on DNS.

It was working and now it is slow

Check whether it is one copy or all of them. One slow copy is usually that copy — it will be replaced. All of them is usually something shared: the database, an external service you call, or your own traffic.

Check the database first. Most "the application is slow" reports are a query that got slower because a table got bigger. It is the single most common cause.

Check whether you are being rate limited by something you call. An external service refusing you produces a slow application, not an error page, if your code retries patiently.

I am being rate limited by the platform

You set that limit. Raise it, or remove it. If you did not set it, someone in your organization did — the history shows who and when.

I lost a password or a key

It cannot be recovered. Secrets are write-only by design: a value you can read back from a web page is a value that leaves in a screenshot. Replace it. Any application using it restarts with the new one.

I deleted something by mistake

An application can be deployed again from the same repository.

A database or a store is gone, along with everything in it, unless you turned backups on. This is why the confirmation is tedious and why the getting started page asks you to turn backups on before you need them.

A domain can be re-attached; the record at your registrar is untouched.

Everything in one region is unreachable

Check the status page before assuming it is you. If a whole region is affected, the platform knows and is working on it; opening a ticket adds nothing but is not discouraged.

What you can do, if you have planned for it: your data in another region, and an application there to serve it. What you cannot do is move a running database between regions during an outage — that copy has to have existed beforehand.

How to ask for help well

Include, in this order:

  1. The application or database, by name.
  2. Its platform address — the one under the platform's domain, which works even when your own name does not.
  3. When it started, as precisely as you can. This is the single most useful thing you can provide and the one most often left out.
  4. What you changed most recently, even if you are sure it is unrelated.
  5. The exact error, copied rather than described.

See Support and availability for what to expect back and how quickly.