> ## Documentation Index
> Fetch the complete documentation index at: https://paper.brimble.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Build minutes
> Every Brimble plan includes a monthly allowance of build minutes, the clock time spent in the builder across all of your projects.
Every Brimble plan includes a monthly allowance of build minutes, the clock time spent in the builder across all of your projects. When the allowance runs out, you can top up with credits that never expire.
## How build minutes are counted
A build minute is one minute of wall-clock time inside the builder, measured from the start of the clone phase to the end of the push phase. It includes:
* Cloning your repo.
* Detecting the framework.
* Installing dependencies.
* Running your build command.
* Pre-start commands (if configured).
* Pushing the artifact to internal storage.
It **does not** include:
* Time spent serving requests (your runtime is billed separately as compute).
* Time the build is queued waiting for a free slot.
* Cancelled builds (if cancelled before the build phase starts; cancelled mid-build still counts what ran).
## Where to see your usage
In the dashboard, build minutes are visible in two places:
1. **Account settings → Billing**, the **Build minutes** card shows used vs. included for the current cycle, with a progress bar and the next reset date.
2. **Home page**, the stats row at the top has a **Build minutes** widget with the same number; click it to jump to the billing page.
## Cycles and resets
Each plan has a monthly cycle. Your **included minutes** reset to the plan's allowance on the cycle's renewal date. The reset date is shown on the card.
**Top-up credits do not reset**, they sit on top of the included minutes and stick around month over month until they're spent.
The order Brimble bills against:
1. Included minutes (this month's allowance).
2. Top-up credits (additive, never expire).
So a fresh cycle uses your monthly allowance first, then dips into credits if needed.
## Top up
When you're running low (or just want a buffer), top up:
1. Open **Billing → Build minutes**.
2. Click **Top up**.
3. Pick a preset amount or enter a custom value:
* Presets: `$5`, `$10`, `$25`, `$50`.
* Minimum custom amount: **\$5**.
4. The modal previews how many minutes the amount buys at the current rate.
5. Confirm. The card on file is charged immediately, and the minutes appear as **top-up credits** on your account.
The conversion rate (minutes per dollar) is set globally and visible in the modal, "X minutes per \$1 · credits never expire."
## What happens when you run out
When used minutes equal included minutes plus credits:
* **Free plan.** New builds queue indefinitely until the next cycle resets your included minutes. There's no overage billing on free.
* **Paid plans.** Builds **don't fail** mid-flight, running builds finish. New builds start to consume top-up credits if you have any. If credits are exhausted, builds queue until the next reset or the next top-up.
A "Builds disabled" state can also show up if billing failed for an extended period, that's separate from running out of minutes. See [Plans and pricing](/billing/plans).
## Estimating your usage
Typical builds:
* **Static site (Vite, Astro, simple Next.js export).** 30 seconds to 2 minutes.
* **Node web service with cache hit.** 30 seconds to 1 minute.
* **Node web service cold.** 1 to 4 minutes.
* **Large Next.js / monorepo build.** 3 to 10 minutes.
* **Python with native deps.** 1 to 5 minutes (cold), 30 seconds (cached).
* **Java / Gradle full build.** 3 to 8 minutes.
Multiply by your number of deploys per day across all projects. A team that pushes 20 times a day across 5 services typically lands somewhere between 200 and 1,500 minutes per month.
## Reduce your build time
A few cheap wins:
* **Don't disable the build cache.** It's on by default; turning it off triples cold-build times.
* **Use a lockfile.** `npm ci`, `pip --require-hashes`, `pnpm --frozen-lockfile` skip dependency resolution.
* **Set watch paths in monorepos.** Pushes that don't touch the project's directory don't trigger a build.
* **Multistage Dockerfiles.** Build in a heavy stage; run from a thin stage. The `docker build` cache reuses layers when only the source changes.
* **Skip unnecessary work in CI/build flows.** Don't run tests in the build phase, run them in your CI before merge instead.
## Troubleshooting
**Top-up confirmed but credits not visible.** Refresh the page. If still missing after a minute, check **Billing → Invoices** for the transaction status, SCA-protected cards sometimes take an extra step to clear.
**My usage looks higher than expected.** Failed builds still count for the time they ran before failing, and builds that hit the build timeout count for the full timeout. Check **Deployment history** for any unusually long deployments and investigate what made them slow.
## Next steps
* [Plans and pricing](/billing/plans), what each plan includes.
* [Builds](../projects/builds), what runs during a build, and how the cache works.