Functions billing

Requests only. What counts, what never counts, and worked examples.

The unit is a request

One invocation dispatched to your function = one billable request.

100,000 invocations are 100,000 billable requests. That is the entire model, and it is deliberate: you can predict your bill from your traffic without modelling your own code.

What is never billed

Not billed	Why
CPU seconds	These are measured operationally — you see duration in logs and latency in metrics — but no plan can price them. There is no such dimension in the billing system.
GB-seconds
Execution duration
Allocated memory
Cold starts, container count, worker minutes

What counts as a request

Exactly one, when the gateway has:

resolved the project,
resolved the function and found a ready deployment,
passed the rate limit and the project's commercial state,
verified the Flares Auth token, if the function requires one,
…and dispatched the request to your runtime.

From that moment it is one request whatever happens next:

Your code returns	Billed
200 OK	1 request
400 / 404 — your own validation	1 request
500 — an uncaught exception	1 request
Timed out or ran out of memory	1 request

The infrastructure ran. Charging differently would mean charging for whether your code succeeded.

What never counts

Anything refused before dispatch, because no execution happened:

Unknown project or unknown function (404)
A disabled function (403)
No ready deployment (503)
Platform rate limit (429)
Suspended project or a hard cap reached
Request body over the size limit (413)
Failed Flares Auth (401) — protecting an endpoint protects your bill

Internal retries never double-bill

Each invocation carries a stable request id, unique in the invocation log. If Flares ever retries an invocation internally after an infrastructure failure, the retry recognises the same id and the meter does not move again: one invocation, one request.

Two requests your own application sends are two requests — retrying a call from your client is your traffic, not ours.

Worked example

Your app makes 1,000 calls to /run/prj_…/create-shipment
  940 return 200                    → 940 requests
   50 return 400 (your validation)  →  50 requests
   10 throw and return 500          →  10 requests
                                     ───────────
                                       1,000 billable requests

Separately, 4,000 calls arrive without a valid token
  4,000 refused with 401 before dispatch → 0 billable requests

Where you see it

Usage shows function_requests for the period; Billing shows what that costs under your plan, with included allowance and overage. Billing & plans → · Usage metering →