Quotas and lean mode

Four things are worth knowing before you go live: the request quota your plan includes, fair use on Glider (Free), the per-plan ceiling on how long the edge may wait for your origin, and how many services and custom domains your plan includes.

The request quota

The request quota is enforced on Glider (Free) only. Usage is counted in request units, per billing account, over a monthly window that starts when the account moves to Glider, at sign-up or after a paid plan ends, and repeats monthly from there. One billing account can fund several organizations, and their request units count together. Paid plans have no quota: each plan includes a number of request units per monthly billing period, and request units above it are billed as overage, per started million.

Plan	Included request units a month	Above the allowance
Glider (Free)	100K	No overage. Every service the billing account funds is switched to lean mode until the window resets or the plan changes. Glider is offered under fair use.
Jet (Starter)	500K	€6.00 per started 1M request units
Airliner (Business)	5M	€5.00 per started 1M request units
Jumbo (Enterprise)	Per contract	Per contract

Glider (Free) is meant for trying GraphPilot out and for small projects, not for production traffic: it comes with no support commitment, its services run lean once the allowance is used up, and it is offered under fair use.

Emails about the request quota

On Glider (Free), everyone whose role is Admin in an organization the billing account funds gets an email at each of these points:

When	What the email says
The account has used 80% of the request units included in the current window	The share used, the included request units, the day the window resets, and what lean mode would withdraw. Not sent when the allowance is already used up by the time the email goes out: the lean mode email covers it.
The services switch to lean mode because the allowance is used up	The included request units, what lean mode withdraws, and the day full serving returns.
Full serving returns, because the window reset or the plan changed	That edge caching is on again.

Each email goes out once for each crossing: the warning once per window, the other two once per switch. None goes out while the account is locked, or once the deletion of the account has started. Lean mode for an overdue payment sends none of these emails: the overdue payment emails apply then.

Prices exclude VAT. On a paid plan, going over the allowance throttles nothing and switches nothing off: the request units above it are billed. A renewal payment that fails is a different matter: the services run in lean mode until it arrives, and the account is locked if it is still unpaid 14 days after the payment reminder. See overdue payments. “Per started million” means the request units above the allowance are rounded up to whole millions: on Jet, 500,001 request units in a period are billed as 1M of overage, and so are 1,500,000; 1,500,001 are billed as 2M.

Request units

Requests are counted per request at each point of presence, and by response size. Every edge location that runs a request counts it once, weighted by the response body that location produced:

sum, over the edge locations a request passed through, of the size units of the body each one produced = request units

Without shielding that is one location, so a request uses the size units of its response. With shielding, the bodies the shield returns to the edge location and the edge location sends to the client are usually the same size, so a request through the shield uses twice the size units of its response.

Edge locations. A request that goes through the shield counts at two edge locations, the one that received it and the shield. Every other request counts at one: a cache hit, a request on a service without shielding, and one that never reaches the shield. A background refresh through the shield, after a stale copy was served, is a request of its own, counted at the shield.

Size units. One per started 10 KiB (10,240 bytes) of the uncompressed response body, headers excluded, at least one. At the edge location that received the request, the size is the body GraphPilot sends to the client; at the shield, the body the shield returns to the edge location, which the edge location asks for uncompressed. Both are measured before any compression on the way to the client, which is also how the CDN bills a compressed response, so the same query costs the same whatever the client’s Accept-Encoding. A response without a body (a HEAD request, a 204 or a 304) is one size unit.

Request	Response body	Request units
Answered from the edge location’s cache	2 KB	1 × 1 = 1
A cache miss on a service without shielding	25 KB	1 × 3 = 3
A cache miss sent through the shield	25 KB	2 × 3 = 6
A `HEAD` request, a `204` or a `304`, sent through the shield	none	2 × 1 = 2
A background refresh through the shield of a 25 KB entry	25 KB	1 × 3 = 3

Shielding is available on paid plans only, so on Glider (Free) every request counts at one edge location, by size. Glider’s quota is counted in request units too.

Every request your service runs counts, whoever sent it and however it ends; the one exception is a purge through GraphPilot (below). That includes the requests the edge refuses before your origin sees them: a credential the service does not accept, such as a token whose signature does not verify (401); an operation that is not on the service’s allowlist (403); a request over one of the service’s request limits (413 or 400); a request from a client the service does not accept (403). Flood traffic counts the same way, request by request, whether or not the edge refuses it. A refused request counts at the edge location that refused it, with the size units of its error response, usually one. Edge codes lists every refusal.

Purges through GraphPilot are free. A call to the purge endpoint that fails authentication, answered 401, counts as one request unit, like any other request someone sends to your service.

Two figures are not counted in request units:

Insights counts every request a client sent once, whatever its size or route, and shows no background refreshes. The request units for a period are therefore higher than the request count Insights shows whenever responses are larger than 10 KiB or requests go through the shield.
Logged requests, the Insights meter of the paid plans, count each logged request once. Glider (Free) has no such meter: recording stops with lean mode when the request units are used up.

To estimate the request units of a traffic profile, use the pricing calculator.

Example: a month of traffic

shop-api serves 2,000,000 requests a month with shielding on. 70% are answered from the edge location’s cache, with a 4 KB body; the other 30% are misses that go through the shield, with a 25 KB body:

Requests	Count	Request units each	Request units
Cache hits at the edge location, 4 KB	1,400,000	1 × 1 = 1	1,400,000
Misses through the shield, 25 KB	600,000	2 × 3 = 6	3,600,000
Total	2,000,000		5,000,000

Insights shows 2M requests for the month; usage shows 5M request units. That fits within Airliner’s 5M exactly, and on Jet it is 4.5M request units above the allowance, billed as 5M of overage because overage is counted per started million. Background refreshes through the shield and refused requests add to the total, so leave headroom. Without shielding, the same misses use 3 request units each, 3.2M request units in total.

Lean mode

Lean mode removes the paid feature set, which today means edge caching and stored request telemetry, and nothing else.

Still runs	Withdrawn
Authentication and claim resolution	Cache lookups: every request goes to your origin
Policy expressions and vary headers	Cache writes: no response is stored
Request signing	The `gp-cache` and `gp-cache-reason` headers (a request that bypasses the cache still reports `PASS`)
Usage counting: request units are still counted and billed against the allowance	Stored request telemetry and logs: requests and log lines are not recorded (see below)
Invalidation

Four consequences follow, and all four are deliberate.

Your API keeps working. A quota is not a kill switch. Requests are still authenticated, still signed and still forwarded. What you lose is the speed and the origin offload, which is what you were paying for. The one thing that can stop a Glider (Free) account is fair use, far above the request quota.

Your origin takes the full load. Every request reaches it, including the ones a warm cache had been absorbing. If your origin was sized behind a cache, this is the number to plan for.

Responses carry no gp-cache header. The cache steps aside entirely, so there is no status to report. A response through GraphPilot without gp-cache, while response.cache_headers is on, is the sign that the service runs lean. See troubleshooting.

Nothing is recorded while lean. See the next section.

Nothing is recorded in lean mode

Requests served while the billing account runs lean are not recorded: no request telemetry and no log lines are stored for them, for any service the account funds. They are not held back or hidden. They are never written, so:

Insights, the service Dashboard, the Purges page and gpilot requests show no requests from the lean window, and purgeByRequest cannot resolve one.
An upgrade does not bring them back. Recording resumes for requests served after the plan changes (or the monthly window resets), and the lean window stays empty in every request view.
They are still counted. The usage figure on the billing page and in the API includes the request units of every request served in lean mode, because counting does not depend on recording. That is the number your allowance and any invoice are based on.

If you need a record of every request, upgrade before the allowance runs out. The billing page shows how much of it is used.

The portal says so wherever it matters: a Paid features are paused notice below the toolbar of every organization page, with Upgrade (or Contact support if GraphPilot paused the account), and empty states on Insights and Purges that name lean mode as the cause. See paid features are paused.

Invalidation keeps running

Purging is not withdrawn in lean mode, and that is not an oversight. A mutation served during a lean window still invalidates entries written before it. If it did not, those entries would come back live and stale the moment normal service resumed, and nothing would have recorded that they were wrong.

Purging a key nothing holds removes nothing, so this costs one call per mutation carrying surrogate keys, on exactly the services that are not generating most of the traffic.

Fair use

Glider (Free) is meant for side projects and for trying GraphPilot out. Lean mode keeps a Glider account serving above its request quota, but Glider is offered under fair use: if an account’s traffic goes far beyond what Glider is meant for, GraphPilot may suspend its services and lock the account until the start of the next month, or until it moves to a paid plan. Nothing is deleted. Paid plans have no such limit: their usage above the plan’s allowance is billed as overage.

Per billing account, across every organization and service it funds, like the request quota.
Per month (UTC). The month starts on the 1st at 00:00 UTC, whatever day the request quota’s window starts on. For an account that moved to Glider from a paid plan during the month, usage counts from the move, so nothing used on the paid plan counts, and a warning or a lock from before the move no longer applies.
Lean mode does not stop the count. Requests served in lean mode count toward fair use like any other, whether or not they are recorded.

What happens:

Step	What happens
Warning	One warning email a month, while the account is not locked, to the billing contacts of every organization the account funds, and a notice on every page of those organizations. Nothing changes in how the services are served. A warning usually comes before a lock; traffic that rises very quickly can lead to a lock without one.
Lock	The account is locked: every service it funds is suspended, the same way as for an overdue payment. The API behind them is no longer served, nothing is deleted (services, configuration, domains and deployments are kept), and the GraphPilot API refuses every change outside billing with `ACCOUNT_LOCKED` and `extensions.reason` `FREE_TIER`. A lock email names the day the lock lifts.

The lock lifts at the start of the next month, or at once on a paid plan. The services are then redeployed, usually within minutes, and an email says the account is active again:

On its own at the start of the next month (UTC), within its first hour.
At once when the account moves to a paid plan. Billing stays open while the account is locked, and a paid plan can be chosen on the billing page, once no invoice is outstanding: while a payment is overdue, the invoice has to be paid first.

More rules:

The payment lock and the fair-use lock never lift each other. An account has one lock at a time, and a locked account is not locked again under fair use. When an account on Glider pays off an overdue payment, it is unlocked as usual, its services are redeployed, and an email says it is active again. If its traffic this month still goes beyond fair use, it is locked under fair use again, with its own lock email. The start of a month does not lift a lock for an overdue payment.
A payment reminder keeps running under a fair-use lock. If a payment reminder is open when the account is locked under fair use, and its deadline passes unpaid, the account is then locked for the overdue payment instead. The start of the next month lifts only a fair-use lock: an open reminder keeps its deadline, and an unpaid invoice stays owed.
A fair-use lock does not delay a payment reminder. If a payment becomes overdue while the account is already locked under fair use, the payment reminder goes out within the hour all the same, and its 14 days run from that reminder, not from the end of the fair-use lock. The account stays locked under fair use until the deadline passes; then the lock for the overdue payment replaces it, as above. Paying before the deadline ends the reminder and leaves the fair-use lock as it is.
A lock by support replaces a fair-use lock, and so does a lock for an overdue payment. Once that lock lifts within the month, the account is locked under fair use again if its traffic this month still goes beyond it. If support lifts a fair-use lock instead, it stays lifted for the rest of that month.

The portal shows both states below the toolbar: see fair use.

Request telemetry

What is stored, up to which allowance and for how long, is on what Insights needs. A service can also store less on its own, with telemetry.record; requests it leaves out are still counted against the allowance. In lean mode nothing is stored, and that window is not filled in later: see nothing is recorded in lean mode. Without stored telemetry, the Insights request views, the Purges page and gpilot requests have nothing to show, and purgeByRequest has no request to resolve. In the portal, an empty request log and an empty purge history say that nothing is recorded in lean mode rather than that nothing matched, and the usage figures keep counting.

Origin timeout ceilings

How long the edge may wait for your origin’s first response byte depends on your plan. A deployment configuring more than its plan allows is refused, not quietly reduced. The table and the reasoning are on what your plan allows.

Services and custom domains

Services are capped per plan, counted across every organization your billing account funds. Creating a service past the cap is refused with SERVICE_QUOTA_EXCEEDED (“Your plan’s service limit is reached”).
Custom domains are available from Jet (Starter) and are also counted across the whole billing account, not per service. Adding one on Glider (Free) is refused with DOMAIN_NOT_IN_PLAN, and adding one past the plan’s allowance with DOMAIN_QUOTA_EXCEEDED.
A billing account funds at most 3 organizations, on every plan. Creating a fourth is refused with ORGANIZATION_QUOTA_EXCEEDED before anything is created. Deleting an organization frees its place; to fund more, contact support. See organizations per billing account.

The numbers for each plan are on the pricing page. Contact support if you need more.

What has no limit

No rate limit and no request cap at the edge. GraphPilot imposes no per-second limit and no cap on requests in flight. See limits. This is a technical statement, not a promise of unlimited use: Glider’s allowance still applies, Glider (Free) is offered under fair use, and GraphPilot can lock an account that misuses the service, for example with traffic far above its plan’s allowance, traffic generated without a real use case, or attacks sent through the platform.
No cap on schemas or on surrogate keys per service, beyond the 16,000 bytes of keys per cache entry.
No cap on purges. The purge API bounds one call at 1000 keys; it does not bound how many calls you make.

Seeing where you stand

Usage is in the portal on the organization’s Billing page. Because the quota is counted per billing account, that is where it is shown, not in an organization’s settings. See billing and usage.