Your latest deployment of soza-aio has been sitting in the queue since 05:33 UTC, and none of your workspace's three build and deploy slots are in use by any other deployment, so it is not waiting behind your own concurrency limit.

To help pin down why it is not starting, could you share how this deploy was triggered (a GitHub push, a redeploy from the dashboard, or the CLI) and a screenshot of the deployment as it appears in your dashboard, including any message shown under its status?

s I made changes on GitHub then I pushed, and the deployment didn't build straight away as usual, this time it was queued

Your soza-aio deployment from that push is still queued, and your workspace has no other builds or deploys in progress, so it isn't waiting behind your own concurrency limit.

To try starting it fresh, open the service, press Cmd+K (Ctrl+K on Windows) and choose Deploy Latest Commit, or push a new commit. If the build then reports it is unable to pull the repository, reconnect GitHub in your Account Settings, confirm the Railway GitHub App still has access to the repository, and disconnect and reconnect the repository in the service's Settings before deploying the latest commit again.

I'm not using a desktop, how do I reconnect my github account to railway?

You can do the reconnect from a mobile browser too: open railway.com/account, reconnect GitHub there, and confirm the Railway GitHub App still has access to the repository. Then open the soza-aio service's Settings, disconnect and reconnect the repository, and trigger a fresh deploy by pushing a new commit.

k If I want to disconnect and reconnect the repository, should the queued deployment be deleted first?

You don't need to delete the queued deployment before you disconnect and reconnect the repository. The steps are the same: reconnect GitHub in your account settings, confirm the Railway GitHub App still has access to the repository, disconnect and reconnect the repository in the soza-aio service's Settings, then push a new commit to start a fresh deploy.

The deployment from your earlier push is still queued since 05:33 UTC, and it isn't waiting behind any other build or deploy in your workspace.

Thanks for the screenshot. Both pushes for soza-aio are still queued, the one from 05:33 UTC and the newer one from 06:00 UTC, and none of your workspace's three build and deploy slots are in use, so they are not waiting behind any other deployment of yours. Your active deployment from yesterday is still the one running.

You don't need to delete the queued deployments before disconnecting and reconnecting the repository. Did you complete the GitHub reconnect in your account settings and the repository disconnect and reconnect in the service's Settings before the 06:00 UTC push? If you tap to expand either queued deployment or open its View logs, please share a screenshot of anything shown there.

Yes, I have completed connecting github and reconnecting the repository, but the result is still the same, instead the queued is piling up

Then, how?

hello?

I am seeing the same issue today (October 31). A deployment requested at about 05:28 UTC never started initialization/build. I canceled that queued request and retried once at 05:57 UTC; the replacement is also queued with no build/runtime logs, while the previous deployment remains healthy. Trial time and credit remain, and no Limited Access or approval warning is shown. Is there a current build scheduling issue, and should the queued request be left pending?

Yes, until when will queued continue to build and then deploying?

already deployed, thank you

queued again

hello