MY Projects fail to automatically re deploy after commiting to GitHub, it shows queueing instead

Vercel Hobby Deployments Stuck in Queued State Before Build Starts

Summary

I am experiencing a sudden deployment issue on my Vercel Hobby team.

My Vercel projects were deploying normally for several days, with previous deployments completing successfully in approximately 7–13 seconds.

Starting around September 18, 2026, new deployments began getting stuck in "Queued" / "Initializing" and never reaching the actual build stage.

I initially suspected a project-specific issue, but I created a completely new Vercel project using the exact same GitHub repository and the latest commit. The new project is experiencing the same problem.

This makes the issue appear to be unrelated to my project configuration or source code.

Account / Team

Vercel team:

"DEVZIKKY"

Plan:

"Hobby"

Affected projects:

"zmailer"

and newly created:

"zmail"

GitHub repository:

"zikky0001-droid/zmail"

Production branch:

"main"

Repository / Latest Commit

Latest commit:

"ab10878"

Commit message:

"Add CSS variables and themes section"

The commit is shown by GitHub as:

"Verified"

The commit contains only:

"1 file changed" "+1 line"

The changed file is:

"public/api-index.js"

The repository contains a normal static/API project structure including:

"public/" "api/" "templates/" "package.json" "vercel.json"

There are no unusually large changes associated with this deployment.

What was working previously

Before this problem appeared, GitHub pushes were automatically triggering Vercel deployments normally.

Recent successful deployments included:

Commit "3927f20"

Status: Ready
Build duration: approximately 12 seconds

Commit "9deddf8"

Status: Ready
Build duration: approximately 7 seconds

Their build logs showed the normal process:

Vercel build environment started
GitHub repository cloned
Build cache restored
Vercel CLI started
Dependencies installed
Vercel build completed
Deployment completed
Cache uploaded

Therefore the project has successfully built on Vercel before.

Timeline of the current problem

Latest GitHub commit

I pushed commit:

"ab10878"

GitHub shows the commit correctly on "main".

Initially, the automatic Vercel deployment did not appear as expected.

Existing project

The existing Vercel project "zmailer" began having deployments stuck in:

"Initializing"

and/or:

"Queued"

The deployment did not progress normally.

I also attempted to create a deployment manually from Vercel using the latest commit.

The manually created deployment also became stuck.

I investigated project settings

The project uses:

Framework:

"Other"

Root Directory:

"./"

Node.js:

"24.x"

Ignored Build Step:

"Automatic"

Build Machine:

"Basic — 2 vCPUs / 8 GB"

The project had previously deployed successfully using the same general configuration.

I created a completely new Vercel project

To determine whether the problem was specific to the existing "zmailer" project, I created a new Vercel project:

"zmail"

I imported the exact same GitHub repository:

"zikky0001-droid/zmail"

from:

"main"

The new project detected the latest commit:

"ab10878"

However, even this completely new project's initial deployment became:

"Queued"

and remained there.

The new project had no previous deployment history.

This is important because it suggests the issue is not caused by an old queued deployment or corrupted deployment history in the original "zmailer" project.

Build logs

The affected deployments do not reach the normal build stage.

There are no normal build logs showing steps such as:

"Cloning repository"

"Installing dependencies"

"Running vercel build"

"Build Completed"

The deployment remains in the queue before those build steps appear.

Usage / limits checked

I checked the Vercel Team Usage page for the last 30 days.

Important values:

Fast Data Transfer:

"11.93 kB / 100 GB"

Edge Requests:

"3 / 1M"

Function Invocations:

"0 / 1M"

Function Duration:

"0 GB-Hrs / 100 GB-Hrs"

Deployment Storage:

"0 B / 10 GB"

Functions Storage:

"0 B / 10 GB"

Blob Data Storage:

"0 B / 1 GB"

Artifacts:

"0 B"

Build CPU Minutes:

"2m"

There is therefore no indication that Deployment Storage or the major displayed Hobby usage limits have been exhausted.

Concurrent build configuration

The team is on the Hobby plan.

The Team Build and Deployment settings show:

"Disable On-Demand Concurrent Builds"

with the description:

"Run one build at a time. Others queue."

I understand that this can cause deployments to queue.

However, the unusual part is that a completely new Vercel project, with no previous deployment history, also has its first deployment stuck in "Queued" for several minutes without reaching the build stage.

Therefore I am trying to determine whether this is normal Hobby queue behavior or whether my team's build queue is stuck.

Git integration

The original project shows:

Connected Git Repository:

"zikky0001-droid/zmail"

Connected:

"September 15"

The latest GitHub commit is visible and verified.

The new project also successfully detected the same latest commit.

Therefore Vercel is able to see the GitHub repository and commit.

The problem appears to happen after the deployment is created, before the build actually starts.

What I have already tried

I have:

Waited for the queued deployments.
Checked the existing project's deployment history.
Checked the Build and Deployment settings.
Checked the Git integration settings.
Checked the team's usage and storage.
Tried manually creating a deployment from Vercel.
Created a completely new Vercel project using the same GitHub repository.
Tested the latest commit on the new project.

The new project also became stuck in "Queued".

I have not made major changes to the source code to try to work around this.

Expected behavior

I would expect:

"GitHub commit" → "Vercel detects commit" → "Deployment created" → "Queued briefly" → "Initializing" → "Build starts" → "Ready"

Previously, deployments completed in approximately 7–13 seconds.

Current behavior

The current behavior is:

"GitHub commit" → "Vercel detects commit" → "Deployment created" → "Queued" → remains queued → no actual build logs appear

The same behavior occurs in both the existing project and a newly created project.

Request

Could someone please check whether there is a problem with the build queue or deployment scheduling for my Hobby team?

In particular, I would like to know whether:

My team currently has a stuck build occupying the Hobby build slot.
There is an internal queue problem affecting my deployments.
There is an account/team-level restriction that is not visible in the Usage dashboard.
The deployments are waiting for infrastructure capacity.
There is any issue with the Vercel Git/deployment integration.
There is anything I need to do to release or reset the queued deployments.

I would also appreciate confirmation on whether this behavior is expected for Hobby deployments or whether the queue appears abnormal.

I can provide deployment IDs, timestamps, screenshots, and additional logs if needed.

Thank you.

The new-project test is the most useful thing in your report, and it points at the cause rather than ruling one out.

On Hobby the build slot is one per team, not one per project. Build Queues puts it directly: the concurrency queue works from "the number of concurrent build slots available to the team", "Hobby accounts allow one build at a time", and "if all concurrent build slots are in use, new builds are queued until a slot becomes available".

So a single deployment that never released the slot parks every later deployment in Queued, across every project on DEVZIKKY. Creating zmail next to zmailer put the new deployment behind the same blocked slot, which is exactly the result you got.

That fits your timing. Vercel had two incidents on 18 September, both now resolved, and you can see them on the Vercel status history page:

Elevated Errors Triggering Deployments, 20:32 to 21:22 UTC (major)
Deployment stuck in initializing state, 21:36 to 22:31 UTC (minor)

A deployment that got stuck in Initializing during that window does not unstick itself once the incident is over, and it keeps holding the single slot.

What to check

Open Deployments and clear the project filter so you are looking at the whole team, then filter Status by Building and Initializing. Look for the oldest entry that is not Ready, Error or Canceled, most likely one created on 18 September between roughly 20:30 and 22:30 UTC.

What to do

Cancel that deployment from its three-dot menu, or open it and use Cancel. That releases the slot. Then push a commit, or use Redeploy on the latest Ready deployment.

Worth knowing: the 45-minute build limit only starts counting once a build is actually running, so a deployment stuck before the build stage can sit there indefinitely. Cancelling is the way out. The Start Building Now button is the documented way to force a queued build past the queue, but it belongs to on-demand concurrent builds, which is a paid-plan feature, so it will not help here.

If nothing is stuck

Then check the rate limits, which are also per team on Hobby: 100 deployments per day, 100 per hour, and 60 per five minutes (Limits, Rate limits table). A retry loop reaches the five-minute one quickly, and new deployments are held until the window rolls over.

If the team-wide Deployments list shows nothing in Building or Initializing and you are inside those limits, post the timestamp of your oldest queued deployment and I will take another look.