Skip to main content

Bandwidth

Bandwidth is how much traffic your published sites serve in a calendar month: their pages, and the video, audio and files they serve from your media library. Video, audio, file downloads and other media served from our servers count 1.6× toward bandwidth, because serving them costs more than serving pages. Every plan includes an amount. What happens when you pass it is the part worth reading, because it is not the same on Free as it is on a paid plan.

Plan availability

Every plan has a bandwidth allowance. On a paid plan going past it is metered and billed, and your sites keep serving. On Free it is a hard stop: the site is paused until the start of the next month.

What each plan includes​

PlanIncluded bandwidth per monthPast the allowance
Free2 GBSites are paused until the start of next month
Starter20 GBKeeps serving; the extra is billed
Pro30 GBKeeps serving; the extra is billed
Business45 GBKeeps serving; the extra is billed
Scale70 GBKeeps serving; the extra is billed
Advanced80 GBKeeps serving; the extra is billed
Agency395 GBKeeps serving; the extra is billed
Enterprise790 GB by default; more by agreementKeeps serving; not billed — your agreement sets the terms

The allowance is per organization, across every site in it — not per site. If you run four sites on one Business plan, they share the 45 GB.

Where to see your usage​

  1. In the console, open Billing from the organization menu.
  2. Find the Usage card.
  3. Read the row labeled Bandwidth (this month, organization).

The meter resets on the first of each month, in UTC.

You do not have to be watching it. Organization admins get an in-app notification and an email at 75%, 80% and 90% of the allowance and again at 100% — each step once a month, and only the highest step reached, so a busy day that jumps from 70% to 95% sends one 90% notice. What those messages say depends on your plan, and the difference is the point:

  • On a paid plan the 100% message reads "You're past your included monthly bandwidth — extra usage is now billed", and tells you the overage appears on your monthly invoice.
  • On Free it reads "You've reached your monthly bandwidth limit", and points you at Billing to upgrade — because on Free there is no overage to bill, only a stop.

What a paused Free site looks like​

When a Free organization passes its band, its published sites stop serving pages and answer with a plain notice instead, and the video, audio and files in its media library stop loading until the pause lifts:

Over the monthly traffic limit

This site has used all of the traffic included with it this month, so its pages are paused until the start of next month. Nothing is wrong with your connection, and nothing here has been removed.

Three things are true about that page and are worth knowing before you see it:

  • Nothing is deleted. Your pages, media, datasets and settings are untouched. The console keeps working normally — only the public site is paused, along with the video, audio and files your media library serves. Those stop wherever they load from, the media library's own previews included, because every play is delivered the same way; images keep loading.
  • It clears itself. The pause is stamped with the month it belongs to. When the month turns over it stops applying, with no action from you and nothing to un-set.
  • Upgrading lifts it within about a minute. The check re-reads your plan every time, so a plan change releases the pause without waiting for the next month or for any sweep to run.

Search engines are told not to index the notice, so a pause does not cost you your rankings.

Why a site can go over before it is paused​

Usage is totalled where it is already counted — page views at the analytics beacon, and video and files where the media library serves them, each on a sampled cadence — so a Free site can pass its band and keep serving for a few hundred more views, or a few dozen more megabytes of video, before the pause takes hold. That is deliberate: the alternative is metering every single request, which would put a database read on every page of every site on the platform to answer a question only Free organizations can ever fail. The allowance is a monthly budget, not a per-second valve.

A daily job re-checks the same thing organization-wide, so an organization running more than one site is still totalled across all of them.

The reverse is much faster still: an upgrade releases within roughly a minute.

Reducing bandwidth​

Your meter counts page views, not what a page weighs, plus the video and files your media library serves, by their size. Every counted view moves it by the same fixed amount, and every gigabyte of video moves it by 1.6 gigabytes (see How usage is counted), so using less of the allowance means having fewer views counted and serving less video.

  • Check Analytics → Traffic for a page that is unexpectedly popular. Views of that page are what move the meter.
  • Check a video's or file's delivery figures in the media library for one that is played or downloaded more than you expected — including from somewhere other than your site, since its link works anywhere. A long video placed on a busy page is usually the largest single use of the allowance.
  • Stop counting your own visits while you check your pages, with ?aglyn_internal=1 (see Which views are counted). Previews and the design canvas are never counted.
  • If the traffic is real and you need more room, the lever is a plan with a larger band.

What a page's images weigh does not change the meter, but its video does:

  • Images. A 4 MB photograph costs your visitors load time, not allowance. Serving a smaller image through CDN delivery makes the page faster; it does not stretch your band.
  • Video, audio and files. Every byte your media library sends of a video, an audio file, a PDF or another document counts 1.6× toward the allowance, wherever it is played or downloaded from. A seek counts the part the player asked for, not the whole file again. A shorter clip, a smaller encoding, or a poster frame that loads before anyone presses play all use less.

Reference​

For developers and operators. None of this is needed to use the feature.

How usage is counted​

Bandwidth from pages is derived from page views rather than measured byte-for-byte at the edge. The platform uses a fixed accounting figure of 1,012.8 KB per page view and converts in both directions, so the meter you read in GB and the counters the analytics pipeline writes are the same number expressed differently. On Free, 2 GB works out to roughly 2,070 page views a month; on Starter, 20 GB is roughly 20,700, and the same division gives every other band.

Video, audio and files are measured: the media library counts the bytes each request sends, and converts them through the same 1,012.8 KB at 1.6×, so a gigabyte of video takes 1.6 GB of the band, and past the band those 1.6 GB are billed at the page-view rate. Video, audio, file downloads and other media served from our servers count 1.6× toward bandwidth, because serving them costs more than serving pages: pages are mostly answered from the CDN's cache, while video and files are sent from our servers and from storage on every request, so each gigabyte pays for both. The weight is the smallest that keeps video at cost plus 30%, after card fees, the same as everything else metered — both inside your allowance and past it. Storing a file is billed separately, as storage, and is not counted again here. A video the platform serves from a delivery partner rather than from its own servers counts the same way, at the file's size each time a viewer starts it, and so does a members-only video or a paid download from your store, each time a buyer opens its link.

Public images are the exception — they are part of what a page weighs, which the 1,012.8 KB already includes, so counting them again would charge for them twice. A private image, which only a signed link opens (a paid download, say), is not on any page, so it counts like a file. Your own team previewing a private file in the console never counts.

Which views are counted​

A view is counted when a published page reports one from a visitor's browser. Two kinds of traffic are deliberately not counted, so they neither bill nor consume your band:

  • Views served by a preview or development build. Only a real production deployment reports. A local development server and a preview URL serve your pages without moving your meter. (A self-hosted deployment at a real domain is a production deployment and counts normally; one served over localhost does not.)
  • Your own browser, once you tell the platform it is yours. Visit any page of your site with ?aglyn_internal=1 on the URL and that browser stops being counted on that site — useful while you are checking your own pages. The visit carrying the parameter is not counted either. The setting lives in that browser and lasts until you clear its storage or visit with ?aglyn_internal=0, and it is per site address, so set it once per domain you want to exclude.

Editing your site does not count either: the design canvas and the console's preview never report a view, so building a page is free however long you spend on it.

That 1,012.8 KB is a billing convention, not a measurement of your pages. It is set from a real cold load of one of our own published pages, which measures 976.1 KB, and it is set slightly above that measurement on purpose: the convention is the figure your allowance is charged at, so erring high means the next correction can only be downward.

The figure was 600 KB until September 2026, when it was brought into line with the page the platform actually serves. If you are comparing an older invoice or an older reading of the meter, the same traffic now converts to more gigabytes — the traffic did not change, the accounting figure did, and it is the gigabyte bands that are the promise. That change moved no plan's band.

Two things follow. Pages heavier than 1,012.8 KB do not consume your allowance faster — the counter moves per view, whatever the page weighs. And a page you make lighter does not stretch the allowance further, for the same reason: if you want more views, the lever is the plan's band, not the page.

Page views are read from the per-host analytics/{YYYY-MM-DD} documents that already exist for the Analytics pages, and video and file bytes from the mediaBandwidthBytes field the media library adds to the same documents (and to the organization's own, for its shared library) in the write that records each delivery — evaluating a cap adds no Firestore reads to the serving path, and counting video adds no writes.

The two mechanisms​

There are two independent protections, and they behave differently. A description that mentions only one of them is incomplete.

Bandwidth capAbuse ceiling
Applies toFree organizations onlyAny plan
Trips at1× the plan's band3× the plan's band (minimum 100,000 page views)
Decided byThe analytics beacon and the media library's delivery route, sampled — plus the daily usage job organization-wideThe analytics beacon, sampled
Recorded onorgs/{orgId}.bandwidthCaphosts/{hostId}.bandwidthCeiling
Enforced atEdge middleware and the page loader; the media library's delivery route for video and filesThe page loader; the media library's delivery route for video and files
LatencyMinutesMinutes
Visitor seesThe "Over the monthly traffic limit" noticeThe "This site is temporarily unavailable" notice, on Free only

The abuse ceiling exists for runaway traffic — a scraper or a loop. On a plan that meters overage it flags the site and pages staff but changes nothing a visitor sees, because that traffic is billed rather than refused. Only on a plan that cannot meter (Free) does it degrade what is served.

The cap is evaluated before the ceiling, so a Free site over its band reads the plan-limit wording rather than an abuse notice.

What a visitor's browser gets​

The cap is enforced in edge middleware, ahead of the ISR cache — a cached page cannot outlive the pause. Every matched path is rewritten to a handler that answers:

  • 503 Service Unavailable
  • Retry-After: 3600
  • Cache-Control: no-store
  • <meta name="robots" content="noindex"> in a self-contained HTML body with no scripts

A staff lockdown outranks a cap — a suspended site serves the lockdown notice, not this one.

The page loader repeats the check as defense in depth and renders the same wording as a 200 with robots: { index: false }; that path exists for anything the middleware matcher does not cover.

A video, audio file or document requested from the media library while either protection holds is answered 503 Service Unavailable with Retry-After: 3600 and Cache-Control: no-store. Images keep serving.

Fail-open, on purpose​

Every layer of this check fails open. A thrown organization read, an unreachable verdict route, a non-200, unparseable JSON, or an older deployment that does not return the field at all — all of them keep serving. Refusing to serve a customer's site because an internal check could not be completed is the worse failure of the two.

Note that attribution on the same response fails closed; the two are deliberately opposite.

Self-hosting​

The cap is engaged by the analytics beacon at /api/analytics/collect and by the media route at /api/media/cdn, neither of which needs a scheduled job or a secret — a deployment that serves pages or video caps them. The daily usage job at /api/billing/usage-alerts (gated on CRON_SECRET) engages the same cap organization-wide and sends the usage emails; a deployment that never invokes it still caps, but loses the alerts and the multi-site total — see Self-hosting.