Fluid Compute

Most functions don't compute. They wait. A function that calls a database, an external API, or your own slow inventory lookup spends 80% of its lifetime doing nothing in particular, letting cycles tick by while it waits for someone else to respond. Until Fluid Compute, you paid for all of that nothing.

Saturday's stock-check route is a clean example. It simulates an 800-millisecond API call. Of those 800ms, maybe 50ms is your code actually running. The other 750 is sitting on its hands. Fluid Compute changes the billing so the expensive meter, CPU time, only runs while your code does. You still pay for provisioned memory across the full duration, but at a much lower rate. Same code, same response time, fraction of the bill.

It's a single toggle. Most new Vercel projects have it on by default. If Saturday was deployed before the rollout, or you imported it from a template that pinned the older runtime, it'll be off. Let's check and flip it.

Outcome

Fluid Compute is enabled on Saturday, and Observability confirms the billing model has switched to active-CPU pricing.

Hands-on exercise 3.1

This is the easiest, highest-leverage change in the course.

Requirements:

1. Open Saturday > Settings > Functions
2. Look for the Fluid Compute section. If it shows Enabled, you can skip the toggle but still complete the verification steps. If it shows Disabled, turn it on.
3. Redeploy Saturday. You can trigger this from the dashboard (Deployments > redeploy latest) or by pushing an empty commit (git commit --allow-empty -m "chore: redeploy with fluid compute")
4. Wait for the new production deployment to finish
5. Hit the stock-check endpoint at least 5 times to generate some invocation data
6. Open Saturday > Observability > Functions and look at the row for /api/stock-check

Implementation hints:

• Fluid Compute applies on the next deployment after you enable it. The setting flips immediately, but existing functions continue running on their old runtime until you ship a new version.
• The Observability metric to look at is the active duration (sometimes labeled "GB-seconds" or "Compute") versus the wall duration. Wall stays around 800ms because the simulated warehouse call still takes 800ms. Active duration should drop to single-digit or low double-digit milliseconds.
• If you don't see the new metrics, give Vercel a minute. Function metrics roll up on a short delay, not in real time.
• This toggle is per-project. If you have other Vercel projects that pre-date Fluid Compute, this is your reminder to enable them too.

Try It

Send 5 requests to the stock-check endpoint:

for i in {1..5}; do
  curl -s -X POST https://YOUR_DOMAIN/api/stock-check \
    -H "Content-Type: application/json" \
    -d '{"sku":"sat-foundry-onyx","size":10}' \
    | jq
done

You should see results like:

{ "available": true, "count": 5 }
{ "available": true, "count": 5 }
{ "available": true, "count": 5 }
{ "available": true, "count": 5 }
{ "available": true, "count": 5 }

Now open Saturday > Observability > Functions. Filter to the last 15 minutes. You should see /api/stock-check with metrics like:

Path                      Invocations   Avg Duration   Avg Compute
/api/stock-check          5             805 ms         12 ms

That 805ms is wall time, basically unchanged. The 12ms is the CPU time you're billed for. There's still a small provisioned-memory charge that runs the full 805ms, but the expensive meter stopped at 12. The difference between the two columns is the value of Fluid Compute.

If you're seeing one number and not two, your project might still be on the legacy runtime or your account might not have surfaced the new metric yet. The Settings > Functions page tells you which runtime is active.

Done-When

• Saturday > Settings > Functions shows Fluid Compute as Enabled
• A redeploy has happened after the toggle
• You can find invocations of /api/stock-check in Observability > Functions
• The compute (active) duration is meaningfully lower than the wall duration

Troubleshooting

The compute and wall durations look identical.

Probably one of two things. Either the function isn't actually awaiting anything (a pure-compute function legitimately has no wait time, and Fluid Compute doesn't help it), or the redeploy hasn't happened yet. Push an empty commit and check again after the next deployment.

The toggle says "Enabled" but I see no change in metrics.

Confirm that the deployment you're hitting was built AFTER the toggle was flipped. Open the deployment from Observability > Functions and check its build timestamp against when you toggled the setting. If the build is older, redeploy.

My function got faster, not just cheaper.

Sometimes happens. Fluid Compute can also reduce cold-start time on the first invocation in a region. If your function felt sluggish before and feels snappier now, that's the same change paying you twice.

Solution

There's no code in this lesson. The implementation is the toggle.

If you want to be extra cautious about catching future projects, set yourself a calendar reminder to check the Functions tab of any new Vercel project you create for the next year. Most will have Fluid Compute on by default, but inherited templates and imported configurations can quietly pin you to the older runtime.

Up next: Fluid Compute makes invocations cheaper. Caching makes invocations not happen in the first place.