Elastic Build Machines feedback thread

Mehul Kar · 2026-09-21 18:27:37.380743+00

Elastic Build Machines is generally available to all Pro and Enterprise customers. Leave any feedback here!

Subject line (if posting as a reply, none needed): Elastic moved a 19-second compile to a 30-vCPU Turbo machine: US$ 67 → US$ 1,553 invoice, no notification, support case stalled

, thank you for asking for feedback here. Vercel Support referred me to this thread on October 19 (case CSE_019Dt2DyO7FGHpq7, team team_8T905hmKEI4uP4mUQK2cDbs4, project viva-facil-60). This is the full post-mortem, with every number taken from Vercel's own APIs (FOCUS billing export, /v3/events, deployment list and build logs). I am also answering your question to Brett about notifications at the end.

What Elastic did

Aug 20, 2026: team default build machine changed from Standard to Elastic (dashboard, my account). Elastic is Vercel's default for paid teams and is documented as cost optimisation ("prevents over-provisioning").
Oct 2, 15:44 UTC: event project-build-machine-updated, isSystemInitiated: true, reason long-build-duration: Standard (4 vCPU) → Enhanced (8 vCPU), triggered by one 5.4-minute build.
Oct 5, 20:04 UTC: same event, same reason, algorithm v19: Enhanced → Turbo (30 vCPU), triggered by one 5.1-minute build whose log reads "Compiled successfully in 19.2s" and "Generating static pages (456/456) in 3.1s".
No email, no dashboard notice, nothing mentioning "build machine", "Elastic" or "Turbo" in 90 days of Vercel emails. The machine stayed on Turbo until I found it and pinned Standard on Oct 12.

What it cost

	Previous cycle	Cycle Sep 11 – Oct 10
Invoice	US$ 67.66	US$ 1,552.93
Build CPU Minutes	small	432,672 min = US$ 1,498.34
Of which Turbo (confirmed by Support)	0	377,580 min

Build CPU Minutes per day went from US$ 10–35 (Standard, Sep 29 – Oct 2) to US$ 260, 198, 562, 107, 154 and 67 (Turbo, Oct 5–10). Six days of Turbo = US$ 1,347. The Turbo machine was also applied to 1,898 preview builds of work branches, which had nothing to do with the triggering build.

Builds got slower, not faster

Median metered build duration on the same project, all 6,703 deployments of the period: 1.49 min on Standard, 3.26 min on Enhanced, 5.38 min on Turbo (previews: 2.07 → 4.96 min). The reason catalogue in the project API includes short-build-duration for downgrades; over seven days and 2,239 builds on Turbo no downgrade ever happened. The docs promise "the assignment is reevaluated as your project changes over time, so it stays right-sized" and that Elastic "detects" under-utilised Turbo machines and "assigns a smaller machine". Neither happened.

What Support confirmed, in writing, in the case

377,580 of the 432,672 billed CPU minutes ran on Turbo.
The long step was not compile and not the disabled build cache: it was the Deploying Output step (packaging and uploading large functions), and that step "contributes to the Elastic upgrade and is part of its algorithm".
"Upgrading to a higher-end machine did not reduce the time taken by the Deploying Output step."

So, by Vercel's own analysis: the trigger was upload time, which is network- and disk-bound; the remedy was 7.5× more vCPUs; the vCPUs could not and did not shorten the step that triggered them; and, since billable duration = (build + post-build minutes) × vCPUs (changelog "Deployments now show billable duration and CPU minutes"), the 30-vCPU rate was charged on exactly the minutes the upgrade could not accelerate. The reason recorded was long-build-duration, not sustained-high-cpu or high-peak-memory: Vercel's own CPU-pressure signal never fired.

Where the case stands

Oct 15: Support offered a one-time 25 % goodwill refund of the Build CPU Minutes line (US$ 374.59), conditioned on enabling a spend limit with pause and reviewing on-demand concurrency. Both done the same day (US$ 100 budget, pause ON; elasticConcurrencyEnabled: false on all 15 projects).
Oct 15 and Oct 19: I asked for the 377,580 Turbo minutes to be re-rated as Standard (377,580 × 4/30 = 50,344 CPU minutes), a credit of US$ 1,145.33, invoice corrected to US$ 407.60, which I will pay immediately. I also asked for a billing manager and for a written hold on collection while the case is open.
Since Oct 19, 12:33 UTC: no reply. Meanwhile the card has been retried automatically seven times (latest Oct 22, 20:38 UTC), each with a "Payment failed and shutdown coming soon" email. The shutdown date communicated is around Oct 26.

Requests

, can you get a human from Billing to pick up case CSE_019Dt2DyO7FGHpq7 before the Oct 26 shutdown, and put collection on hold while it is reviewed? Brett above is stuck at the same dead end with a different team.
Product: Elastic should not be allowed to upgrade on long-build-duration alone when the long step is Deploying Output. Upload time is not a CPU problem, and sustained-high-cpu already exists as the right signal.
Product: a per-team cap ("never above Standard/Enhanced") and a downgrade that actually fires.

On your notification question (before or after)

Before, with the price. A spend alert at 50 % of budget is not notice of a change in unit rate: by the time my first alert arrived (Oct 6, 01:34 UTC), the project had already been 29 hours on Turbo and one day had cost US$ 260; the 100 % alert came when the cycle was already ten times my previous invoice, and none of them said what had changed or which setting to touch. The notice that would have prevented this is: "Elastic is about to move project X from 4 to 30 vCPUs; estimated cost per build goes from A to B; click to keep the current machine." After the fact is better than nothing, but it still leaves the customer paying for the hours until they read it.

I have the FOCUS export, the event log and the deployment durations and will share them with anyone at Vercel who asks. I would still much rather settle this on a corrected invoice than keep writing about it.

Emer Gomes