Functions billing

The plans, how a month is totalled, what counts as a request and what never does.

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

Storing your code is not charged for

Flares measures how many bytes of deployed code your project is keeping — every version of every function, including the ones kept so you can roll back — and shows you the figure under Usage. It is not billable. No plan can put a price on it, and no invoice can carry a line for it.

It is measured because you should be able to see what you are storing. That is the only reason.

Measured	How
Bytes of deployed code	Every deployment of every function in the project.
When	Re-measured the moment a deployment is written, not by a nightly job.
Counted as	What you are storing now — not a total that grows each day you keep it.
Charged	Never.

Requests are the only Functions meter that becomes money. Deploying — however large — bills no request, and calling your function — however long it runs — costs nothing beyond that one request.

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

The plans

Every Functions plan is three numbers: a monthly fee, an allowance of requests, and a price for each additional million. Plans are priced in US dollars. If you are billed in naira, the dollar figure is converted at the rate Flares currently uses for billing, and the rate that applied is recorded on the invoice so an old total can always be explained.

See the current plans and prices →

How a month is totalled

The monthly fee, plus the requests you went over your allowance — charged in whole millions, because part of a million is charged as a million.

monthly fee
  + ceil(requests over the allowance ÷ 1,000,000) × price per million
  ─────────────────────────────────────────────────────────────────
  = what you pay this month

So on a plan costing $3 a month with 10 million requests included, at $0.25 per extra million:

Requests in the month	Over the allowance	Total
1,000	none	$3.00
10,000,000	none	$3.00
10,000,001	1 request — one whole block	$3.25
12,000,000	2 million	$3.50
13,000,000	3 million	$3.75

The allowance is counted across the whole project, not per function. Twelve million requests spread over six functions is twelve million requests.

Functions is billed separately from your database

A project holds a Basket DB plan and a Functions plan at the same time, and they are independent: changing one does not touch the other, and the allowance on one is never consumed by the other. Both appear on the same invoice, as separate lines.

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 →