Lovable usage limits: choose an alert or block with live-app impact in view
A usage limit can do more than stop someone from building in Lovable. Depending on its scope and credit type, it can also pause Cloud, AI features, or metered connector requests inside a published app. Before choosing “block,” check what the rule covers and what your live product depends on.
Lovable’s October 7, 2026 changelog says paid-workspace owners and admins can set a credit threshold, choose a scope and credit type, and select an alert, a block, or both. The detailed usage-limits guide explains how those choices interact. This is a configuration decision for a specific workspace, not a universal recommendation: the right action depends on whether your goal is to notify a person, cap build activity, or pause usage that serves app users.
Separate the warning from the limit
Lovable has two related controls with different jobs:
- A usage limit watches credits spent over a daily or monthly period. When its threshold is reached, it can notify, block, or do both.
- A low-balance alert watches the credits left in the workspace. It can send an email or in-app notification, but it never blocks usage.
Use the low-balance alert for an early warning; use a usage limit to define what happens after a scope spends its threshold. They are not interchangeable: a low-balance alert never stops usage, while a blocking usage limit can interrupt a feature.
The feature is available to owners and admins on paid plans. Editors can see the limits that apply to them and their projects, but cannot create or change them.
Start with the scope, not the threshold
Every usage limit combines four settings: threshold, scope, credit type, and action. Decide what you are trying to control before choosing a number. A workspace-wide rule and a project-specific rule can reach very different people and app behavior, even when their thresholds match.
| Scope | What it covers | Important boundary |
|---|---|---|
| Workspace | All credit usage across the workspace | Broadest reach across projects |
| Project | All projects or one selected project | A project default gives each project its own allowance |
| Member | All members or one selected member | Build usage only |
| Group | Each member of a selected group | Business and Enterprise; Build usage only |
| Access token | Requests authenticated with one token | Business and Enterprise; all credit types except Connectors |
Project and member defaults are per-project or per-member allowances, not a shared pool. A project default of 100 credits, for example, gives each covered project its own allowance. Group limits likewise give each current member a separate allowance. For user and group scopes, only Build usage can be limited; deployed-app Run usage belongs to the project, not the person who built it. If your concern is a published app’s backend or AI use, a member-level Build limit does not cap that runtime activity.
11 production screens. Login, database, payments — all wired.
The SaaS Dashboard Kit ships everything already connected. Nothing to set up. Live demo at saas.otf-kit.dev.
Match the credit type to the behavior you need to control
The credit type determines what usage counts toward the threshold. Build covers building and editing the app, chat usage, and image or video generation. Run covers what a deployed app uses: Cloud, AI, and connector activity. Cloud includes hosting and the built-in backend; AI covers model calls made by app features; Connectors covers metered connector requests. A broader General limit includes all credit usage.
Build limits stop covered people from asking Lovable to build or edit apps; they do not cap deployed-app Run usage. To control live Cloud, AI, or connector activity, choose the corresponding project or workspace scope and credit type.
For a workspace or project rule, the guide maps blocking actions to the selected credit type:
- Build: stop building.
- Cloud: pause Lovable Cloud features.
- AI: pause AI features in the covered projects.
- Connectors: pause metered connector requests from the covered apps.
- Run: pause Cloud, AI features, and metered connector requests.
- General: block all usage for the scope, including building and running apps.
Access-token limits block requests made with that token; they do not pause a project. The settings use slightly different labels for token rules. Read the actual behavior shown in the dialog instead of inferring it from the word “block.”
Decide whether an alert or a block fits
An alert-only usage limit gives an owner or admin a signal when usage reaches the threshold without stopping the covered activity. That is the lower-interruption choice when you want to review usage and respond yourself. A blocking rule enforces a boundary automatically. For Build, that means covered people cannot continue building. For runtime types, it can pause the corresponding features in deployed apps.
A practical selection sequence is:
- Name the outcome you need: notification, build cap, runtime cap, or token-request cap.
- Choose the narrowest scope that actually covers the usage you mean to control.
- Select the credit type that corresponds to that activity.
- Choose notify, block, or both, then read the confirmation screen for any app behavior it will pause.
- Check whether a default or existing rule already applies to the same scope, type, and period.
New limits start with blocking and email alerts enabled. You can turn blocking off for a notify-only rule and select email or in-app notifications. If a limit pauses Cloud, AI features, or connector requests, Lovable asks you to confirm before saving and explains what will pause and where.
Understand the live-app consequence before confirming
A workspace or project limit that blocks Cloud usage can pause the Lovable Cloud backend for every project it covers, including published apps. The app’s page may still load, but its database, login, storage, and backend features stop working for its users. The project cannot be woken up while the limit is triggered. An AI or connector limit can pause those app features; a Run limit combines Cloud, AI, and connector effects.
That makes the confirmation step part of the production change. Check which projects are included, whether they have a live audience, and which app behaviors depend on the selected credit type. A workspace-wide Cloud or General block has broader impact than a project rule. If you only need an owner to notice increasing spend, a low-balance alert or notify-only usage limit may fit the goal without intentionally pausing an app.
Pausing Cloud does not delete the stored files, and those files continue to use credits while the project is paused. Removing Cloud is a separate, permanent action that deletes the Cloud instance; it is not a way to clear a usage block casually. Adding credits or upgrading a plan also does not lift a triggered usage block, because the rule counts what has already been spent during the current period. The documented ways to lift it are to raise the limit, disable its blocking behavior, delete it, or wait for the period to reset.
Know the edge cases before relying on a hard cap
Usage is recorded before limits are evaluated, so a hard limit can be exceeded slightly before the block takes effect. Treat the threshold as a guardrail, not a mathematically exact ceiling. Blocking limits also enter an “Approaching” state at 80% of their threshold. If notifications are enabled, that state can provide an earlier warning before the block triggers.
Daily periods reset at 00:00 UTC; monthly periods reset on the first day of the month at 00:00 UTC, independently of the billing cycle. A specific limit can override a matching default only when the credit type and period match. Different types or periods can continue to apply alongside one another. If you create a limit with the same scope, credit type, and period as an existing rule, Lovable asks you to overwrite it rather than add a duplicate.
Members who hit a blocking limit can request an increase. Owners and admins review the request and can approve it indefinitely or until the end of the usage period. An approval for a default limit creates an override for that member or project; it does not raise the default for everyone. Group and access-token limits do not support increase requests.
Make the setting match the operating risk
Before saving, record the rule’s scope, type, period, and action, then identify what stops if it triggers. Use an alert when an operator should decide what to do; use a block only when the interruption is acceptable and the app owner knows how to lift it.
For cost planning across a Lovable build, see our guide to the cost curve from prototype to production. For a broader decision about whether Lovable fits your workflow, use the Lovable comparison; this checklist is about configuring a limit inside a Lovable workspace, not comparing products.
Sources
- Lovable, “Set credit usage limits and alerts for your workspace”, October 7, 2026; checked October 9, 2026. The changelog summarizes who can configure limits, available scopes, actions, and app behavior.
- Lovable, “Usage limits and alerts”, checked October 9, 2026. The detailed guide describes scope, credit types, periods, warnings, blocking effects, and limitations.
Ship the product, not the setup.
- 11 production screens — auth, billing, team, analytics, settings
- Real database, payments, and login — all wired on day 1
- AI configs pre-tuned so your agent extends instead of regenerates