Hello Vercel team,
Could a staff member review a production-state inconsistency and advise on the safest supported reconciliation? The custom production domain is working, so we want to preserve its availability and the existing verified deployment.
I have anonymised all project, team, deployment and domain identifiers in this public report. Exact identifiers and timestamped evidence can be provided through a Vercel-approved private channel.
Observed state from a read-only investigation on 6 October 2026:
| Surface | Observed state |
|---|---|
| Custom production domain | Serves NEW |
| Dashboard | NEW is Production — Current; Promote is disabled |
| Project targets.production | Still OLD |
| NEW | READY / target=production / readySubstate=STAGED |
| OLD | READY / target=production / readySubstate=PROMOTED |
| Default project production domain | Still serves OLD |
| Automatic team alias | Maps to NEW |
| Promote-alias mapping for custom domain | pending, also returned with failedOnly=true |
| lastAliasRequest | null |
| lastRollbackTarget | null |
| rollingRelease | null |
The supported promotion/rollback status logic exposes no active operation. We cannot rule out hidden provider bookkeeping. promotedAt is not exposed in our readbacks and must not be assumed null.
Sequence:
- An earlier rollback preceded this release; autoAssignCustomDomains is false and updatedBy=system. Current rollback mode is not proven.
- NEW was built as a production-targeted STAGED deployment and verified.
- Our release tooling directly assigned the custom production domain to NEW before formal promotion.
- A subsequent bodiless POST /v10/projects/{projectId}/promote/{deploymentId}?teamId={teamId} returned HTTP 409 on 6 October 2026. The original response body, headers and request ID were unfortunately not retained.
- A later read-only investigation confirmed the split state above. No rebuild, alias experiment or promotion retry was performed during that investigation.
Closely matching Community reports:
- #49312: STAGED candidate, old production pointer, already-current 409
- #48975: promotion 409, pending alias and null lastAliasRequest
These are analogous reports, not proof of our original 409 reason. Our hypothesis is that directly assigning the production alias, and possibly the automatic team alias, made NEW count as already current for promotion eligibility while the formal production pointer remained OLD.
Could Vercel please:
- Provide a private route for the exact IDs, original request time and timestamped provider readbacks, so staff can identify the server-side 409 reason?
- Explain what the pending mapping represents when lastAliasRequest is null, and how it can safely be cleared or reconciled?
- Confirm whether direct alias assignment can cause this already-current eligibility conflict?
- Provide an exact supported plan to make the existing verified NEW the formal production deployment, align both production domains and remove unexplained pending state, preferably without rebuilding or disrupting the working custom domain?
- Explain any effect on autoAssignCustomDomains or rollback state before a reconciliation is attempted?
The live custom domain works, but this inconsistency blocks release closure and further production releases. Our self-service review did not establish a safely supported reversible recovery.
We are on Hobby, and the support portal redirected technical case submission to Community. Please investigate read-only first. No deployment, promotion, rollback, alias/domain/settings/DNS/environment/database changes are authorised by this report; please provide the plan before any production mutation.
Thank you.