[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Events](/events) · [Live](/live)
[Feedback](/c/feedback/8)
# Elastic Build Machines feedback thread
0 views · 1 like · 6 posts
Mehul Kar (@mehulkar) · 2026-09-21 · ♥ 1
[Elastic Build Machines](https://vercel.com/docs/builds/managing-builds#elastic-build-machines) is [generally available](https://vercel.com/changelog/elastic-build-machines-is-now-ga) to all Pro and Enterprise customers.
Leave any feedback here!
Brettiredale (@brettiredale) · 2026-10-15
Hi Mehul,
Some feedback from a small Pro team, plus a request for help.
Elastic went live on 21 September. Two to four days later it had moved all four of our projects up to turbo (30 cores), with “sustained-high-cpu” given as the reason. Nobody on our side chose that, and we got no warning. Our build cost went up about 14 times overnight, while each build got faster by under a minute. We only found out when the invoice came.
We’ve moved all four projects back to fixed standard machines. When we asked for a refund, the support bot said the automatic refund limit was reached and that it can’t open a case.
Two requests:
Please let elastic tell customers before it moves them to a more expensive machine, or give us a setting to cap it at standard.
Could someone on the billing team open a private case for us so a person can review the invoice? Team: brettiredale’s projects.
Thanks,
Brett
Mehul Kar (@mehulkar) · 2026-10-16
@brettiredale can you open a support ticket with your teamId? feedback noted on
- build costs going up and build time only improving by 1m
- no notifications. would you want something before or after elastic decides that your build needs more resources?
Brettiredale (@brettiredale) · 2026-10-16
I did open a ticket and it said the amount couldn't be handled by the automated system. The only option it gave was to post here. And yes, I'd think a notification before would be best, but I'd take either.
Brettiredale (@brettiredale) · 2026-10-16
I keep hitting this dead end. How can we get humans involved?
Emergomes2 6131 (@emergomes2-6131) · 2026-10-22
**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
@mehulkar, 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**
1. 377,580 of the 432,672 billed CPU minutes ran on Turbo.
2. 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".
3. "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**
1. @mehulkar, 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.
2. 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.
3. 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