Managed runs stuck Pending with 'Deployment Unhealthy' since Aug 10 — queue pipeline never delivers to the flow endpoint (reproduced on beta.35 and beta.41)

Summary

Since Aug 10 2026 ~15:30 UTC, every managed workflow run in our production project wedges at Pending with the run detail badge Deployment Unhealthy — "Deployment not assigned", attempts 1, next-eligible one second after admission, no heartbeat, never re-driven (24h+). Admission works (start() succeeds, runs appear in the dashboard), but the queue pipeline never delivers to the workflow endpoint: sustained observation of runtime logs shows zero delivery attempts at /.well-known/workflow/v1/flow.

Per the healthCheck docs ("sends a message through the queue pipeline and verifying it is processed by the workflow endpoint… works even when the deployment is behind Deployment Protection"), Deployment Unhealthy appears to mean exactly that queue→endpoint leg is failing — consistent with what we observe from the app side.

What we've eliminated (all verified)

• SDK version: reproduced on workflow@5.0.0-beta.35, then upgraded to 5.0.0-beta.41 (current) — identical behavior. Next.js 16.3.0, app router, basePath: '/v2'.
• The endpoint: POST to the flow route on our production domain answers the handler's own JSON (400 for a bare probe). The generated artifact is present in every build; next start serves it locally.
• Registration staleness: dozens of fresh production deployments across two days (very active repo) — every one shows the same Deployment Unhealthy state; the current one had a run admitted 14 minutes after it went Ready and aliased, which wedged identically.
• App errors: zero workflow-related production errors in our error tracking; the run's Events tab shows the single enqueue event and nothing else.

Likely-relevant platform context

On the same Aug 10 window, Vercel's edge stopped matching static app-router routes under the dotted .well-known/ directory on our deployments (requests fall to /_not-found; the dynamic sibling webhook/[token] still matches; pre-incident deployments that served the flow route while they were current now fail it too — so it is platform-side, not artifact-side). We worked around the public URL half with an afterFiles rewrite to a non-dotted alias route, which restored public HTTP — but managed runs still wedge, which makes sense if the queue invocation layer resolves the workflow function by the same dotted path internally.

Reproducer (happy to share privately with support)

• Run wrun_41KZSF7A1E0GZH3D1C9C1ZTXCE (region IAD1), Pending 2h+ at time of filing, badge Deployment Unhealthy, created Aug 11 22:30 UTC.
• Project has Vercel Authentication (Standard Protection) enabled and no automation bypass secret — per the healthCheck docs that should be irrelevant to the queue path, but noting it for completeness.

Ask

1. What makes the workflow health check mark a deployment Deployment Unhealthy, and how can we see that check's failure reason?
2. Is queue delivery to the workflow endpoint affected by the Aug 10 edge change to dotted-path route resolution?
3. Can the parked runs be re-driven once delivery is restored, or should we cancel and re-emit?

We've filed a support ticket with full project/team identifiers; posting here because the timeline coincides with the beta.39–41 window and this repo moves fast. Thanks!

Start with the healthCheck documentation and trace the queue pipeline to the /.well-known/workflow/v1/flow endpoint, comparing it with the working webhook/[token] route and the reported afterFiles rewrite. Confirm the deployment-health failure reason and whether dotted-path resolution causes the missed delivery; done means documenting the cause and the supported recovery path for parked runs.