Free hosting can be a practical way to launch a small site, but its limits may affect whether that site stays fast, builds successfully, or remains available as it grows. The important detail is that “free” does not describe one standard package: providers set different quotas, reset periods, and responses when a limit is reached, and those terms can change.
This guide explains common limits—bandwidth, build minutes, function execution, storage, and sleeping instances—and gives you a checklist for understanding what your provider will do before you depend on a free plan.
Key takeaways
- A hosting limit is a quota or condition, not necessarily an automatic bill. The outcome may be throttling, failed deployments, paused services, extra charges, or a request to upgrade.
- Quotas can apply to a project, account, team, or billing period. Check the exact scope and reset schedule.
- Static sites, server-rendered apps, and serverless backends consume different resources.
- Track usage and read the current plan terms before a launch or traffic spike. Provider limits and policies can change.
What a hosting limit actually means
A provider may measure a resource over a billing period, a rolling window, or per request. Some limits are hard caps: once reached, a particular operation stops. Others are soft limits: the provider may slow traffic, send a warning, or charge for additional usage if the plan allows it.
The consequences are not interchangeable. A bandwidth cap might affect visitors, while a build-minute cap might prevent a new version from deploying. Reaching a function limit could affect only dynamic features, leaving static pages available—or it could make the whole application unusable, depending on its architecture.
Before relying on a plan, look for four details in its current documentation and pricing terms:
- What is measured? For example, transferred data, build duration, function runtime, or stored bytes.
- How is it measured? Find the unit, time window, and whether usage is pooled across projects.
- What happens at the limit? Look for throttling, suspension, failed jobs, overage billing, or upgrade requirements.
- How do you get service back? The quota may reset, require a plan change, or require manual action.
Bandwidth: data transferred to visitors
Bandwidth, often described as data transfer or egress, generally concerns data sent from the hosting platform to visitors or other destinations. Page HTML, images, downloads, video, and API responses can all contribute. The precise accounting rules depend on the provider and product.
If usage approaches a plan’s allowance, possible outcomes include slower delivery, a temporary restriction, an upgrade prompt, or charges where the plan permits paid overages. Some plans may instead pause a service or enforce a separate fair-use policy. Do not assume which outcome applies based on another provider’s behavior.
Ways to manage it: compress images, avoid unnecessarily large downloads, use appropriate caching, and review traffic and transfer reports. A caching layer can reduce repeated requests to an origin, but its effect depends on cache configuration and what the provider counts.
Build minutes: time spent creating deployments
A build usually runs commands that install dependencies, compile an application, and prepare files for deployment. Build minutes measure some portion of that work, but providers may differ in what counts, how failed builds are treated, and whether usage is shared among projects.
When a build quota is exhausted, a deployment may be delayed or rejected until the quota resets or the account changes plans. Existing deployed files may remain online, but do not count on that without checking the provider’s terms. A failed build can therefore block a release even if the live site still works.
Ways to manage it: avoid triggering unnecessary builds, keep dependencies and build steps lean, and check whether preview deployments consume the same allowance as production deployments. If builds are triggered by repository changes, make sure automated jobs are not rebuilding for irrelevant files.
Function execution: requests, runtime, and resources
Serverless functions and similar hosted compute features can have several separate limits. A plan might track invocations, execution time, memory, CPU, or a combination. A function that runs too long or exceeds its resource allowance may be terminated or rejected. A request quota can be reached even when individual executions are short.
The effects depend on how the application uses functions. A page that needs a function to load essential data may fail when that function is unavailable. A mostly static site may continue to serve its already-published pages while forms, search, or other dynamic features stop working.
Ways to manage it: measure real workloads, set sensible timeouts, avoid doing unnecessary work in request handlers, and monitor errors as well as usage. Do not assume that a function limit is the same as the overall bandwidth or build limit.
Storage: files, databases, and deployment artifacts
“Storage” can refer to several different things: uploaded files, database records, logs, build artifacts, or the files in a deployed site. A provider may set separate quotas for each. A site’s source repository and its hosted storage allowance are not necessarily the same resource.
At capacity, uploads or writes may fail, backups may stop, or a deployment may be blocked. Existing data might remain accessible, but providers’ retention and service policies differ. Treat a storage cap as an operational risk, especially if users can upload files or your application writes data frequently.
Ways to manage it: identify what is consuming space, remove obsolete artifacts where safe, set retention policies for logs and temporary files, and back up important data independently. Before deleting anything, confirm whether the data is still needed and whether removal is reversible.
Sleeping instances and cold starts
Some platforms may stop or idle an instance after a period of inactivity, particularly on certain low-cost or free offerings. When a request arrives later, the platform may need to start the service again. The first request can take longer than requests served by an already-running instance; this delay is commonly called a cold start.
Sleeping is different from reaching a usage quota. It can be an expected behavior of the plan rather than a penalty for high usage. The exact trigger, restart behavior, and performance impact vary by provider and product. If an application must respond promptly at all times, verify the plan’s availability and instance behavior rather than inferring it from the word “hosting.”
Overage policies: check before assuming there will be a bill
An overage policy explains what happens when usage exceeds an allowance. Depending on the plan, the provider may block additional use, reduce service, suspend a resource, offer paid overages, or require an upgrade. Some plans may not allow extra usage at all. Even when a provider offers paid overages, billing controls and account settings can affect whether they are available or enabled.
Read the current pricing page and plan terms for the exact service you use. Look for the price per unit, whether overages are automatic, any spending controls, notification thresholds, and the process for restoring a paused service. A dashboard warning is useful, but it does not replace the written policy.
A practical workflow for checking your plan
- List the services your site depends on. Include the frontend, API functions, database, file uploads, scheduled jobs, and deployment pipeline.
- Find the quota for each service. Record the unit, scope, and reset period. Note whether it is per project or shared across an account.
- Write down the stated consequence. Separate what happens to current traffic from what happens to new builds, writes, or function requests.
- Review billing controls. Confirm whether overages are possible, how charges are calculated, and whether you can set alerts or spending limits.
- Check usage regularly. Compare trends against the quota rather than waiting for a warning. Investigate sudden changes and unexpected build activity.
- Test important failure paths safely. In a non-production environment, confirm that the site communicates errors sensibly if a dependent service is unavailable. Do not deliberately exhaust a live account’s quota.
- Prepare a fallback. Keep source code, configuration, and backups of important data under your control. Know what migration or upgrade steps would be required if the free plan no longer fits.
Common mistakes
- Treating a free tier as a permanent contract. Plans, quotas, and terms can change. Recheck official documentation and pricing before making a long-term decision.
- Looking only at the headline quota. A plan may also limit concurrency, request duration, database capacity, or another resource that matters to your application.
- Assuming all traffic counts the same way. Provider accounting can distinguish between types of transfer or services. Check the current definition rather than guessing.
- Assuming the site will simply stop. Some components may remain available while others fail, or the provider may take a different action entirely.
- Assuming limits reset at the start of each calendar month. The reset may follow a billing cycle or another period. Verify the account’s actual schedule.
- Ignoring user-generated data. Uploads and database writes can grow independently of website traffic and may need their own retention and backup plan.
Recommendations for small sites and indie projects
Start by matching the plan to the application’s architecture. A static site with occasional updates has a different resource profile from an app that runs server-side code on every visit or accepts user uploads. Track each resource separately, and keep a record of the current terms that affect your deployment.
If a limit is close, identify the cause before upgrading or changing architecture. Reducing image sizes may help with transfer, but it will not resolve a build-time quota. Optimizing a function may reduce execution use, but it will not add storage capacity. Address the resource that is actually constrained, and account for the provider’s stated overage and recovery process.
For a production site, also decide what level of interruption is acceptable. A free plan may be suitable for a prototype or low-traffic project, but availability, support, and quota behavior should be evaluated against the site’s needs—not assumed from its current usage.
Conclusion
Free hosting limits explained simply: each provider defines what it measures and what it does when you reach the allowance. Bandwidth, build minutes, function execution, storage, and sleeping behavior affect different parts of a site, while overage policies determine whether service is restricted or extra usage is billed. Check the current official terms for your specific plan, monitor the relevant resources, and prepare for the consequences that matter to your application.