TimedOutBeforeReady means that the server in the session backend did not start listening on port 8080 within 30 seconds of starting.
This issue typically appears in two scenarios:
- Your server is not running on port 8080. If you are using a server framework, you may need to configure it to run on port 8080. You may be able to specify this in the run command in your Dockerfile or in your server code. Check the docs for your particular framework on how to run on port 8080.
- Your session backend takes longer than 30 seconds to start a server.
- You don't have a server running in the session backend.
A failure occurred while loading the Docker image on the Jamsocket platform. This can happen if your Docker image was not built for a Linux x86 architecture. To address this issue, try building specifically for the ARM architecture with the following command:
docker build --platform linux/amd64 ...
Take a look at our quickstart docker step (opens in a new tab) for more details.
ErrorStarting means that the backend exited before reaching a
Ready status. A backend is marked
Ready when it starts a server on port 8080. You can view your backend logs to investigate the cause.
The backend exited on its own with a non-zero status. There are two likely scenarios:
- Your backend was killed for hitting a memory limit. Refer to the backend's page (ie.
app.jamsocket.com/backend/[BACKEND NAME]) on the Jamsocket dashboard to see your memory usage. Contact us to upgrade your Jamsocket plan, if you'd like.
- Your backend code hit an error while running. View your backend logs to investigate the cause.
This error can occur if there was an outage caused by issues from our cloud provider or Jamsocket itself. Refer to our Jamsocket status page (opens in a new tab) to check for a possible outage. Contact us if the issue persists.
The backend exited on its own with a zero status. Likely, you've exited the process (ie.
process.exit) or stopped the server.
In production, you can view your backend logs by running
npx jamsocket logs BACKEND_NAME using the CLI.
In local development with the Dev CLI, the logs will be written to the Terminal. If you aren't seeing the appropriate program logs, compare the logs outputted in Docker using:
docker container ls -l
docker logs CONTAINER_ID
There may two reasons why this error occurs when running
npx jamsocket push or
npx jamsocket dev:
- Docker is not running on your machine. Start Docker (ie. open Docker Desktop) and use
docker psto check that Docker is running.
- You may need to check
Enable default Docker socketunder the Advanced tab in the Docker Desktop settings page.
This error may occur when there is a mismatch between the image tag that an image was pushed with and the image tag that is used to spawn the backend.
- If you push an image with a custom tag, you must also provide that tag at spawn time via the CLI or HTTP API. If the custom tag was not provided at spawn time, Jamsocket will look for an image with the tag
latest. If there is no image with a
latesttag, Jamsocket will return a
- If you push an image without a custom tag, Jamsocket gives that image the tag
When spawning a backend, the URL to connect to that backend contains an Auth Token.
Some frameworks may strip the Auth Token from spawn result URL used to connect to the session backend. Often times, this occurs when the framework is attempting a redirect.
The side effect of this issue is a potential CORS error that looks like this:
Access to fetch at 'http://localhost:9090/example-route' (redirected from 'http://localhost:9090/yK3en1rk87XyblPrFS7TV-JeWKhQ2k_XLYNeneElCYI/example-route/') from origin 'http://localhost:3000' has been blocked by CORS policy
Stripping the Auth Token will result in a failed connection to the session backend, because the Auth Token tells Jamsocket which session backend to route traffic to. Treat the connection token like a bearer token, because any client that knows it can access the backend.