Measure Function Costs on Vercel

Deploy two function versions and compare their CPU cost per thousand requests.

Introduction

30 Second Summary

A deployment can look fast while quietly consuming more compute than you expect. Without billing numbers, a small code choice can become an expensive habit.

In this project, you will deploy two versions of the same function with Vercel. The deployment metrics let you calculate each version's cost per thousand requests.

What You'll Build

You will show two Vercel deployment pages side by side with different CPU totals plus a README that translates the gap into cost per thousand requests.

By the end of this project, you'll have:

A live function you can open at a public URL to confirm it responds.
A repeatable traffic test that gives both deployments the same few hundred requests.
An evidence-backed cost comparison in README, built from the billable duration and CPU minutes reported for both implementations.
Secret Mission: An optional challenge to push your deployment measurement skills further.

Are there any prerequisites?

You'll need a free Vercel account plus Node installed on your computer. No framework knowledge is required.

Before We Start

Reliable cost comparisons depend on both deployments following the same path to Vercel. A missing tool can make the measurements impossible to compare.

Node.js powers the command-line workflow. The Vercel CLI connects your computer to the account that records each deployment.

In this step, get ready to:

Prepare Node.js for local deployment commands.
Make a signed-in Vercel account available.
Prepare a local deployment workspace with the Vercel CLI.

Prepare Node.js

Node.js supplies npm. You use npm to install the deployment tool.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type Terminal on macOS or PowerShell on Windows.
Press Enter to open the terminal application.
Check your installed Node.js release by running this command:

node --version

What does this command show?

The command prints the Node.js release available to your terminal. The result determines whether you can continue or need the current LTS installer.

✔️ I see the current LTS version

Your output should begin with v24. Your Node.js runtime is ready for the Vercel CLI.

ⓧ I see an older version

Your existing installation needs an update. The current LTS release provides the supported runtime for this project.

Open the official Node.js download page in your browser.
Choose the v24.21.0 LTS release.
Download the installer for your operating system.
Run the downloaded installer with its default options.
Check the updated release by running this command:

node --version

What should change?

The output should now begin with v24. This confirms that your terminal can reach the current LTS installation.

ⓧ Command not found

Node.js is missing from your computer. The official installer also adds npm for the CLI installation.

Open the official Node.js download page in your browser.
Choose the v24.21.0 LTS release.
Download the installer for your operating system.
Run the downloaded installer with its default options.
Confirm the installation by running this command:

node --version

What should you see?

The output should begin with v24. This result confirms that Node.js is available in your terminal.

Still seeing the old release?

Start a new terminal session if the old release still appears.
Run the LTS installer again if the installation stopped before completion.

Get help with a Node.js installation that your terminal cannot detect.

Sign in to Vercel

Your Vercel account owns the deployments that you measure. It also gives you access to each deployment page.

The sign-in flow handles your credentials in the browser. Your terminal never needs your account password.

✔️ I already have an account

Open the official Vercel login page in your browser.
Select Continue with Email.
Complete the email verification from your inbox.

You should reach your Vercel dashboard. This confirms that your account is available for deployments.

ⓧ I need an account

Open the official Vercel sign-up page in your browser.
Select Continue with Email.
Complete the email verification from your inbox.

You should reach your new Vercel dashboard. That dashboard is the home for both measured deployments.

Prepare your local deployment workspace

A dedicated folder keeps both function implementations with your final comparison. Placing it on your Desktop makes it easy to find during deployment.

macOS

Click an empty area of your Desktop.
Press Shift-Command-N to create a folder in Finder.
Type deployment-cost-lab as the folder name.
Press Return to save the name.

You should see the deployment-cost-lab folder on your Desktop.

Windows

Press Windows key+E to open File Explorer.
Select Desktop in the left navigation pane.
Press Ctrl+Shift+N to create a folder.
Type deployment-cost-lab as the folder name.
Press Enter to save the name.

You should see the deployment-cost-lab folder on your Desktop.

The CLI installation may take a minute while npm downloads the package. A short pause in the terminal is expected.

Switch back to your terminal.
Install the current Vercel CLI release by running this command:

npm install -g vercel@latest

What does this command do?

The npm command downloads the Vercel CLI package.
The -g option makes the command available from any folder.
The @latest suffix selects the current release.

Confirm that the CLI is available by running this command:

vercel --version

What should you see?

You should see a Vercel CLI version number. This proves that your terminal can run deployment commands.

CLI command unavailable?

Start a new terminal session if the installation completed but the command is unavailable.
Repeat the installation if your connection interrupted the download.

Get help with a Vercel CLI installation that does not return a version number.

The login handoff can feel fiddly because the terminal prints a verification link. Your browser handles the approval without exposing your password in the terminal.

Start the Vercel authentication flow by running this command:

vercel login

What happens during login?

The command starts an OAuth device flow. The terminal waits while you approve access in your browser.

Open the verification link printed in your terminal.
Approve the sign-in request in your browser.
Return to your terminal after Vercel confirms the authentication.

Before you run the final check, which Vercel username do you expect the terminal to return?

Reveal the authenticated account by running this command:

vercel whoami

What does this confirm?

You should see your Vercel username. This proves that future CLI deployments use the account you prepared.

Username not appearing?

Check your browser for an unfinished Vercel verification page.
Repeat the login flow if the earlier verification link expired.
Confirm that your browser uses the intended Vercel account.

Get help with a Vercel login flow that does not return your username.

Your deployment path is ready. Your account can now receive projects from the computer you prepared.

Next, you will deploy the first function and open its public URL.

Deploy the Careful Function

Your cost comparison needs a trustworthy baseline before you add the deliberately slow version.

The careful endpoint keeps reusable work outside the request path. In this step, you deploy it as the first production deployment in Vercel.

In this step, get ready to:

Prepare the careful endpoint to reuse precomputed work.
Create the deployment-cost-comparison project from your project source.
Open the production URL to confirm the endpoint responds successfully.

Prepare the careful baseline

Request-independent work produces the same result on every call. Preparing it outside the handler keeps repeated CPU work out of the request path.

What belongs outside the handler?

Precompute only values that stay identical across requests. This gives the endpoint reusable work for later calls.

Keep values derived from an incoming request inside the handler. Each response must still reflect its caller.

Replace the request-independent calculation inside the endpoint handler with a precomputed value declared outside the handler.
Save the project source.

Create the Vercel project

A Vercel project connects your source to its deployments. The first deployment of a new project becomes a production deployment.

Return to the Vercel dashboard from earlier.
Click Add New… near the top of the dashboard.
Select Project.
Choose the project source that contains your careful endpoint.
Set the project name to deployment-cost-comparison.
Select Deploy to start the deployment.
Wait until the deployment page reports a successful deployment.

The baseline is live. Your project now has a successful production deployment to measure later.

Did the deployment fail?

Inspect the deployment logs for the first failed build step.
Confirm that Vercel is using the folder that contains your endpoint source.
Fix any missing dependency in your project source before redeploying.

Get help with a failed Vercel deployment.

Verify the production URL

Before you open the URL, predict whether the careful endpoint returns a successful response.

Open the generated URL shown for the latest production deployment.

You should see the successful response produced by your careful endpoint. The browser address bar should show its public deployment URL.

Does the public URL fail?

Return to the deployment details to inspect the runtime logs.
Confirm that the URL path matches the route defined by your endpoint.
Redeploy the project after correcting the route or runtime problem.

Get help with an unsuccessful endpoint response.

✔️ My careful baseline is ready

Your careful endpoint is live as the baseline production deployment. Keep this deployment available for the request test in the next step.

ⓧ I'd like to double check

Confirm that the Vercel project is named deployment-cost-comparison.
Confirm that the project is connected to the source containing your careful endpoint.
Confirm that the endpoint prepares reusable work outside the request handler.
Confirm that the latest production deployment completed successfully.
Confirm that its public URL returns a successful response.

Your careful deployment is ready. Next, you will send it a few hundred requests to produce billable duration and CPU minutes.

Measure the Careful Deployment

Your careful endpoint already returns a successful response. That proves the deployment is reachable.

One response cannot create a repeatable traffic sample. You need a fixed request count that you can use again for the slower implementation.

Vercel reports billable duration and CPU minutes on each deployment. In this step, you will send exactly 500 requests before recording both values for the careful deployment.

In this step, get ready to:

Send exactly 500 requests to the careful endpoint.
Open the careful deployment details in Vercel.
Record the careful deployment measurements.

Send 500 requests to the careful endpoint

Your browser can send the full batch from the JavaScript console. Running the script on the careful endpoint page makes that page's URL the request target.

Switch back to the browser tab showing the successful careful endpoint response.
Right-click anywhere on the page.
Select the option that opens your browser's developer tools.
Select the Console panel.

Before you run this, what two numbers should the completion message contain if the full batch returns?

Send the fixed request batch by running this script in the Console panel:

// Create exactly 500 unique requests to the careful endpoint.
const requests = Array.from({ length: 500 }, (_, index) => {
  const requestUrl = new URL(window.location.href)
  requestUrl.searchParams.set("request", index + 1)
  return fetch(requestUrl)
})

// Wait for every request attempt before reporting the result.
const results = await Promise.allSettled(requests)
const returnedResponses = results.filter(result => result.status === "fulfilled").length
console.log(`Sent 500 requests. ${returnedResponses} responses returned.`)

What does this script do?

The first section creates exactly 500 request numbers.
Each request receives a unique query value so the browser treats every URL separately.
The second section waits for every request attempt to finish.
The final message reports how many responses returned without a network error.

Wait for the request batch to finish.
Confirm the Console shows Sent 500 requests. 500 responses returned.

Do the response numbers differ?

Check that the Console is attached to the tab showing the careful endpoint response.
Check the Console for a network error that interrupted one or more responses.
Avoid running the full script again after it has sent the batch because that would add another 500 request attempts.

Need help checking the request batch?

That is your matched traffic sample complete. The careful deployment has now received the request batch you will mirror for the slower version.

Find the careful deployment metrics

The deployment details page keeps the build measurements attached to the exact version that produced them. Selecting the correct production deployment prevents a preview build from entering your baseline.

Before you check the fields, do you expect the 500-request batch to increase these deployment build values?

Return to the Vercel dashboard in a new browser tab.
Select the deployment-cost-comparison project.
Select Deployments in the project sidebar.
Select the successful production deployment whose public URL matches the careful endpoint.
Find the deployment detail labelled billable duration.
Find the deployment detail labelled CPU minutes.

You should see one billable duration value and one CPU minutes value on the careful deployment page.

What do these values measure?

Billable duration combines build time with post-build time. Vercel rounds that total up to the next whole minute.

CPU minutes multiply the billable duration by the build machine's vCPUs. These are deployment build measurements.

The 500 requests create a matched traffic sample for the two implementations. They do not increase these two build values.

Record the careful measurements

A useful baseline keeps both units attached to the correct deployment. Capture the values exactly as Vercel displays them.

Record the value shown for billable duration: your careful billable duration.
Record the value shown for CPU minutes: your careful CPU minutes.
Leave the careful deployment details page open.

Your careful deployment now has a fixed traffic sample and a recorded measurement baseline. Next up, you will deploy the deliberately slower implementation for the same test.

Deploy the Slow Version

Your careful deployment now has measurements from exactly 500 requests. Those numbers are your baseline.

A code change only becomes a useful cost comparison when the test volume stays fixed. In this step, you will make every request repeat the expensive work in a new Vercel deployment.

In this step, get ready to:

Change the endpoint to recompute the expensive work on every request.
Deploy the slow implementation as a new Vercel deployment.
Measure the slow deployment after exactly 500 requests.

Make every request repeat the work

The careful implementation reuses or precomputes the expensive work. The slow implementation places that work inside the request path so each call recomputes it.

Why change only the implementation?

A fair comparison keeps the endpoint behavior consistent while changing how the result is produced. This isolates the compute cost created by repeated work.

The original deployment remains your baseline. The new deployment becomes the deliberately slow test case.

Return to the connected project source from earlier.
Locate the careful endpoint implementation that reuses or precomputes the expensive work.
Change the endpoint so the expensive work runs inside the request handler on every call.
Publish the source change as a new deployment through the connected deployment workflow from earlier.

Deployment processing can take a short while. A changing deployment state means Vercel is building the slow version.

Switch back to the Vercel dashboard from earlier.
Select the newest deployment for deployment-cost-comparison.
Confirm that the newest deployment completed successfully.
Record the slow deployment public URL here: slow deployment public URL.
Open slow deployment public URL in a new browser tab.

You should see the endpoint return the same kind of successful response as the careful version. The endpoint now performs the expensive work for every request.

Slow deployment not responding?

Confirm that the source change created a new deployment for deployment-cost-comparison.
Check that the expensive calculation sits inside the request handler.
Keep the endpoint response in the same format as the careful implementation.

Need help diagnosing the slow deployment?

Send the same request volume

Request volume is the control for this comparison. Sending exactly 500 requests gives both deployments the same workload.

Return to the same request method you used for the careful endpoint.
Set its target to slow deployment public URL.
Send exactly 500 requests to the slow deployment.
Confirm that the completed request total is exactly 500.

You have now given the slow deployment the same 500-request workload as the careful deployment. That matched volume makes the upcoming measurements meaningful.

Request run stopped early?

Note how many requests completed before the run stopped.
Send only the remaining requests needed to reach 500.
Verify that the request target matches slow deployment public URL.

Need help reaching exactly 500 requests?

Record the slow deployment metrics

The deployment page connects the slow implementation to its measured resource use. Its billable duration and CPU minutes become the second half of your comparison.

A short aggregation delay is normal after the request loop finishes.

Before you refresh the deployment page, do you expect the slow version to use the same CPU minutes as the careful version?

Return to the slow deployment details in the Vercel dashboard.
Refresh the deployment page.
Wait until the billable duration reflects the slow deployment traffic.
Wait until the CPU minutes reflect the slow deployment traffic.
Record the billable duration here: slow deployment billable duration.
Record the CPU minutes here: slow deployment CPU minutes.

You should now see billable duration and CPU minutes for the slow deployment after its 500-request run. You have a matched measurement set ready for comparison.

Metrics still catching up?

Allow more time for the deployment metrics to finish aggregating.
Refresh the slow deployment page again.
Confirm that you are viewing the newest deployment for deployment-cost-comparison.

Need help finding the updated measurements?

Your careful deployment and slow deployment now have measurements from the same request volume. Next, you will place those numbers side by side to measure the cost of repeated work.

Compare Deployment Usage

Both versions of your endpoint have now handled exactly 500 requests. Their matched workloads make the implementation the main difference in this comparison.

Next, you will compare the two Vercel deployment pages side by side. This gives you measured evidence of the extra CPU work caused by per-request recomputation.

In this step, get ready to:

Position the two deployment detail pages side by side.
Build a four-value usage comparison.
Calculate the CPU-minute difference between the implementations.

Place the deployments side by side

A fair comparison depends on a matched workload. Both pages belong to deployments that received exactly 500 requests.

Return to the careful deployment detail page from earlier in your first browser window.
Return to the slow deployment detail page from earlier in your second browser window.

You should now have one browser window showing each 500-request deployment.

Arrange the two browser windows side by side using their window controls.
Match each deployment page to its recorded measurement set.

You should see the careful deployment on one side. You should see the deliberately slow deployment on the other side.

Transfer the recorded careful billable duration into your comparison here: careful deployment billable duration.
Transfer the recorded careful CPU minutes into your comparison here: careful deployment CPU minutes.

Your careful deployment column now contains both usage measurements.

Transfer the recorded slow billable duration into your comparison here: slow deployment billable duration.
Transfer the recorded slow CPU minutes into your comparison here: slow deployment CPU minutes.

Your comparison now contains the same two measurements for both implementations. That matched structure makes the difference easier to trace back to the code.

Compare the two usage signals

Why Keep Both Metrics?

Billable duration gives you one view of deployment usage. CPU minutes measures the processor time consumed by each deployment.

Keeping the measurements separate prevents elapsed execution time from hiding CPU-heavy work.

Compare the careful billable duration with the slow billable duration.
Mark the deployment with the larger billable duration in your comparison.

Your comparison now identifies which implementation accumulated more billable duration.

Compare the careful CPU minutes with the slow CPU minutes.
Mark the deployment with the larger CPU-minute total in your comparison.

You can now see whether per-request recomputation increased processor usage across the matched workload.

Calculate the CPU-minute difference

The final comparison needs one number that expresses the CPU gap. Subtracting the careful value from the slow value keeps the direction consistent.

Before you calculate it, do you expect the CPU-minute difference to be positive, zero, or negative?

Calculate the difference by subtracting the careful CPU minutes from the slow CPU minutes.
Record the result here: CPU-minute difference.

A positive result means the slow deployment consumed more CPU minutes across the same 500 requests.

You should now have two 500-request columns. Each column should include billable duration and CPU minutes.

Your final line should show the slow CPU minutes minus the careful CPU minutes.

Does the Difference Look Backwards?

Confirm that you subtracted the careful CPU minutes from the slow CPU minutes.
Check that both values came from CPU minutes instead of billable duration.
Verify that each measurement belongs to its 500-request deployment.

Help me check my CPU-minute comparison.

That comparison is complete. You now have deployment evidence linking an implementation choice to measurable CPU usage.

Next, you will turn these measurements into a cost per thousand requests for each version.

Document the Cost per Thousand

You have already compared the careful and slow Vercel deployments under the same 500-request workload. The recorded billable duration and CPU minutes show what each implementation consumed.

Raw readings only describe the workload you tested. This step scales both CPU measurements to 1,000 requests. You will preserve the evidence in README.md.

In this step, get ready to:

Calculate CPU minutes per 1,000 requests for each deployment.
Document both 500-request measurement sets in README.md.
Complete a reproducible comparison of the two implementations.

Calculate CPU minutes per 1,000 requests

A per-1,000 figure creates a common traffic scale. This comparison uses CPU minutes as its measured cost signal.

How the Normalization Works

The same formula applies to both versions. Each observed CPU measurement is divided by 500. The result is multiplied by 1,000.

Each deployment received exactly 500 requests. The normalized figure is therefore twice the observed CPU minutes.

Calculate the careful result using your recorded careful CPU minutes divided by 500 and multiplied by 1,000.
Record the careful result here: careful CPU minutes per 1,000 requests.

The careful measurement now represents a 1,000-request workload.

Calculate the slow result using your recorded slow CPU minutes divided by 500 and multiplied by 1,000.
Record the slow result here: slow CPU minutes per 1,000 requests.

Good work. Both implementations now have CPU figures at the same traffic scale.

Write the deployment measurements

A README turns your measurements into a durable project artifact. Its structure should let another person trace every normalized result back to the matching deployment.

What Each Deployment Section Needs

Create one section for the careful deployment. Create another section for the slow deployment.

Include the workload of 500 requests.
Include the observed billable duration.
Include the observed CPU minutes.
Include the CPU minutes per 1,000 requests formula and result.

Return to the project source connected to deployment-cost-comparison in your code editor from earlier.
Create README.md at the top level of the project source using the editor's new-file control.

You should see README.md beside the existing project files in the editor's file sidebar.

Enter Deployment Cost Comparison as the top-level heading.
Add a Careful Deployment section containing the four entries above.

You should see the careful deployment's 500-request workload beside its observed measurements. The section should also show its normalization formula and result.

Add a Slow Deployment section containing the same four entries for the slow version.

You should now see two sections with matching request counts. Each section should contain measurements from its corresponding deployment.

Save README.md.

Complete and verify the comparison

The final comparison connects the two measurement sets. It records how much more CPU the slow implementation consumed at the tested workload.

Add a Comparison section containing the recorded CPU-minute difference.
Add careful CPU minutes per 1,000 requests to the comparison.

The comparison now connects the careful result to the measured difference.

Add slow CPU minutes per 1,000 requests to the comparison.
Save README.md.

Before you inspect the finished file, which entries should let another person reproduce both normalized results?

Compare the careful section with your recorded careful deployment measurements.
Compare the slow section with your recorded slow deployment measurements.
Confirm that both calculations divide the observed CPU minutes by 500 before multiplying by 1,000.
Confirm that the CPU-minute difference matches your side-by-side deployment comparison.

You should see one README.md file containing both observed billable durations. It should contain both observed CPU measurements. It should also contain the CPU-minute difference plus both normalized calculations.

Does the README Miss a Number?

Match each observed value to the notes from the corresponding deployment.
Check that both deployment sections use exactly 500 requests.
Recalculate a normalized result if it does not equal the observed CPU minutes divided by 500 and multiplied by 1,000.

Get help checking your deployment comparison.

That completes the evidence trail. Your README now connects an implementation choice to measured CPU usage at a shared traffic level.

Secret mission

Forecast CPU Use at Scale

Turn your 500-request results into a forecast for 100,000 requests. Quantify the CPU minutes saved by the careful version. Finish with an optimization recommendation backed by your own measurements.

Clean Up Your Resources

Your 500-request comparison cost $0 on Vercel's Hobby plan. The deliberately slow public deployment remains reachable after the experiment.

Decide whether to keep both deployments available, pause further testing, or delete the deliberately slow deployment while preserving README.md.

Resources you used:

The deliberately slow deployment in deployment-cost-comparison, identified by the billable duration and CPU minutes recorded after 500 requests.

Keep everything running

No action is needed. Choose this option if you are still comparing the two implementations.

Keep the deployment-cost-comparison project available while you review its measurements.
Preserve README.md as the written record of both 500-request tests.
Avoid sharing the deliberately slow deployment's public URL.

The deliberately slow endpoint remains publicly reachable with this option.

Pause - I'll come back to this later

Pause the experiment by stopping further requests. Keep the deployment pages available for your next comparison.

Keep every request loop stopped.
Preserve README.md with the measurements from both deployments.
Leave both deployments unchanged until you are ready to continue.

Both public deployment URLs remain available during this pause.

Delete - I don't want to use this again

Remove the deliberately slow deployment while preserving README.md as your project artifact.

Deleting the slow deployment is permanent. Your recorded comparison remains safe in README.md.

Telling the deployment records apart is a little fiddly because both received exactly 500 requests.

Return to your signed-in Vercel account.
Select the deployment-cost-comparison project.
Open the project's deployment list.
Identify the deliberately slow deployment by matching its recorded CPU minutes with README.md.
Open the deliberately slow deployment's details page.
Use the deletion control on that deployment page.
Confirm the permanent deletion when prompted.
Return to the project's deployment list.

You should no longer see the deliberately slow deployment in the list. The careful deployment remains available as your baseline.

That's the risky version removed. Your README.md still holds the evidence from both 500-request runs.

Nice Work!

You did it! You deployed a careful version of the endpoint beside a deliberately slow version on Vercel. Measurements from exactly 500 requests per deployment now support a written comparison grounded in billable duration and CPU minutes.

You've learned how to:

Deploy two implementations of the same endpoint. Drive exactly 500 requests through each public URL.
Read billable duration and CPU minutes from each deployment. Trace the CPU-minute difference back to repeated computation.
Calculate CPU minutes per 1,000 requests from your own measurements. Preserve the comparison in README.md.
Secret Mission: Take on an optional challenge to push your deployment cost analysis further.

Ready to quiz yourself?