Netlify’s pricing works like most modern hosting: a flat plan fee plus metered usage, where several different activities draw down from a shared allowance - which is why the bill is hard to predict and easy to be surprised by.
People searching for what a host costs usually want a single number, and there is no longer a single number to give them. The plan fee is the small part. The useful skill is understanding which activities are metered and which one of them your particular site will hit first.
Table of contents
- Flat fee plus meter, and why the meter dominates
- The five things that get metered
- Why the horror stories happen
- Estimating your bill before it exists
- Reducing the number
- How this fits the rest of the stack
- FAQ
Flat fee plus meter, and why the meter dominates
The shape is consistent across the industry now. You pick a plan with a monthly price and an included allowance. Usage beyond the allowance is billed at a per-unit rate, or on some plans it simply stops.
Netlify expresses this as credits: a single unit that production deploys, compute, bandwidth, web requests, and form submissions all draw from. Other hosts meter each dimension separately. The mechanics differ; the consequence does not. Your bill is driven by what your site does, not by what plan you are on.
This is genuinely better than the old model for most people - a small site costs almost nothing, and you are not paying for a server sitting idle. It is worse in exactly one way: you cannot know the number in advance, and the failure mode is a bill rather than a slowdown.
The five things that get metered
- Bandwidth. Every byte served to visitors. Dominated by images and video, and the single most underestimated line for content-heavy sites.
- Requests. Every page view, asset fetch, API call, and redirect. A page with sixty small assets costs sixty requests, which is why bundling and caching are financial decisions and not just performance ones.
- Compute. Serverless function execution, measured in resource-time rather than invocations. A slow function costs more than a fast one at the same traffic, so server-rendered pages are metered by how long they take to render.
- Production deploys. Each deploy to production consumes allowance. A pipeline that deploys on every commit to main burns this faster than most people expect.
- Everything else. Form submissions, preview environments, extra concurrent builds, additional team seats. Individually small, collectively the reason a bill does not match the estimate.
The pattern worth internalising: for a static marketing site, bandwidth dominates. For a server-rendered application, compute dominates. For an API-backed app with a chatty frontend, requests dominate. Work out which one you are before estimating anything.
Why the horror stories happen
There is a well-circulated case of a developer receiving an enormous invoice for a static site after a scraper hammered it for a few days. Cases like that are rare and they are not really about one host - they are about the structural properties of metered billing without a ceiling.
Three things have to line up. Usage is metered per unit with no hard cap. Something abnormal happens - a scraper, a bot, an accidental infinite loop in a client, a viral link. And nobody notices for days because alerts were never configured.
The defences are boring and effective. Find out whether your plan is hard-capped or bills overage. If it bills overage, check whether auto-recharge is enabled by default and decide deliberately. Set a spending alert well below the number that would hurt. And put a rate limit or a CDN cache in front of anything large and publicly reachable.
Note that a hard-capped plan trades this risk for the opposite one: your site pauses instead of billing. That is the right trade for a side project and the wrong one for anything with revenue attached.
Estimating your bill before it exists
- Measure page weight. Load your heaviest page and read the total transferred. Multiply by expected monthly page views. That is your bandwidth floor, before assets shared across pages and caching.
- Count requests per page view. Open the network panel. Multiply by page views. This is the number people never check and it is often the binding constraint.
- Estimate compute honestly. For server-rendered routes, measure how long a render actually takes and multiply by the routes that are not cached. If everything is static, this is zero and your life is simpler.
- Count deploys. How many times a week does main change? Multiply by four.
- Add a safety factor. Double it. Traffic is spiky, caches miss, and the estimate above assumes nothing goes wrong.
Doing this takes twenty minutes and turns hosting cost from an anxiety into a line in a budget. It also usually reveals that the biggest lever is not the host at all - it is the eight-megabyte hero image nobody compressed.
Reducing the number
Almost every meaningful saving is an engineering change rather than a plan change. Compress and resize images, and serve modern formats. Set long cache headers on anything with a content hash in the filename so repeat visitors cost nothing. Put a CDN in front of your API responses where they are cacheable at all. Make server-rendered routes static where the content does not actually change per request.
On the deploy side, stop building on every commit to every branch, and let preview deploys expire. On the seat side, check whether your plan charges per member before adding the whole team.
The alternative model is worth knowing about too: plans priced on the resources you provision rather than on the traffic you receive. You pick a plan size and a bandwidth allowance, and the bill is the same whether the site is quiet or busy. That is less efficient when traffic is low and much easier to forecast, which for a business site is usually the more valuable property.
How this fits the rest of the stack
Whichever host you land on, the exercise is the same: get the number onto a page before the traffic arrives. The RunxBuild hosting calculator lists the service, the database, the storage, and the bandwidth as separate line items so the total is a fixed figure rather than a range that depends on a good month. On RunxBuild, static sites include 120GB of bandwidth and are $0.10/GB beyond it, and services sit on a published plan ladder from a $4 Dev plan upward, so the forecast is arithmetic rather than estimation.
Useful related references:
- Netlify Forms: What You Get Free, and Where the Ceiling Is
- Netlify and SEO: The Platform Settings That Actually Affect Rankings
- Netlify Drop: The Fastest Way to Put a Folder on the Internet
- Services on RunxBuild
FAQ
How much does Netlify cost?
There is no single figure: it is a flat monthly plan fee plus metered usage, where deploys, compute, bandwidth, requests, and form submissions all draw from a shared credit allowance. The plan fee is the small part for most sites. Check the current pricing page for the figures, since they change.
Why is my hosting bill higher than expected?
Usually one of three things: images pushing bandwidth far past the estimate, a chatty frontend making many small requests per page view, or server-rendered routes consuming compute time. Measure page weight and request count in your browser’s network panel before blaming the plan.
Can I get a surprise bill from a static site?
Yes, if the plan meters usage with overage enabled and something abnormal happens - a scraper, a bot, or a viral link - and no alert is configured. Set a spending limit well below the painful number, check whether auto-recharge is on by default, and cache aggressively.
How do I estimate hosting costs in advance?
Measure the transferred size of your heaviest page and the number of requests it makes, multiply both by expected monthly page views, add compute time for any non-cached server-rendered routes, count weekly deploys, then double the total as a safety factor.
Is usage-based or fixed pricing better?
Usage-based is cheaper when traffic is low and unpredictable when it is not. Fixed pricing on provisioned resources costs more for a quiet site and gives you a number you can put in a budget. For anything with revenue attached, forecastability is usually worth more than the saving.