[INDEX] // ALL_DOCS ›
[TOC] // ON_THIS_PAGE ›
Your team shares one compute balance across its repositories and workflows. Pay-as-you-go purchases and subscriptions fund that balance; usage draws it down at the runner’s per-minute rate. See Pricing for compute and storage rates.
Concurrency and runtime limits
| Team | Concurrent runners | Maximum job runtime |
|---|---|---|
| Non-paying | 1 | 30 minutes |
| Pay-as-you-go, after buying compute | 5 | GitHub’s 5-day limit |
| Developer | 25 | GitHub’s 5-day limit |
| Growth | 30 | GitHub’s 5-day limit |
| Pro | 40 | GitHub’s 5-day limit |
| Business | 50 | GitHub’s 5-day limit |
Buying compute or subscribing removes the non-paying 30-minute limit. Starter credit and promotional grants alone do not count as a purchase or unlock paid limits. Your team still needs sufficient balance to start a job. GitHub’s workflow-level limit is 35 days, including queue time; a lower timeout-minutes in your workflow can end a job sooner.
The concurrency cap is shared across the team, including jobs from different repositories. Buying pay-as-you-go compute unlocks five slots without a monthly subscription. A subscriber who also buys extra compute keeps their plan’s higher cap.
What happens above the cap?
Jobs wait in arrival order until a slot frees, for up to six hours. If no slot becomes available within that admission window, the job fails rather than waiting indefinitely. Cancelling a waiting job in GitHub removes it from the queue. A runner reclaimed before starting its job and retried onto on-demand joins the back of the line.
This admission queue is separate from waiting for cloud capacity: an available team slot does not guarantee the requested runner can be provisioned. Waiting for cloud capacity uses your team’s capacity-wait setting, which defaults to 15 minutes, rather than the six-hour admission window. Allowing more regions or enabling on-demand fallback gives the provisioner more options.
For matrix sweeps, use strategy.max-parallel to impose a lower parallelism limit. Size large sweeps so waiting jobs can obtain a slot within the admission window. See Parallel hyperparameter tuning.
Auto top-up
A team administrator can enable Auto Top-Up in Settings → Credits:
- Make sure the team has a saved payment method.
- Select Enable Auto Top-Up.
- When the balance drops below $5, machine.dev automatically charges the saved payment method $20 and adds that amount to the balance.
The amount and threshold are fixed. There is no daily top-up cap: if continued usage keeps the balance below $5, further top-ups can occur. Select Disable Auto Top-Up to stop future automatic charges. Stripe sends invoices and receipts to the billing email.
If no usable payment method is available, the team receives a low-balance warning instead. A terminal payment decline disables auto top-up and falls back to the warning; temporary payment failures can be retried. Check your payment method and re-enable the setting after resolving a decline.
Auto top-up does not reserve funds or override admission checks. Keep enough balance for your workload, especially when many jobs finish together. Jobs refused for insufficient balance need to be re-run after adding compute.
Invoices and payment methods
Team admins can open Stripe’s customer portal from either Settings → Credits or Settings → Subscription:
- Find the Billing & invoices card.
- Select Manage billing.
- View and download invoices, update the billing email, or manage payment methods in Stripe.
New compute purchases, automatic top-ups and subscription payments use Stripe invoices. Stripe handles invoice and receipt email delivery. Team members can view usage in machine.dev, but only admins can manage billing. If the portal is unavailable, check that your team has a Stripe billing account or contact support@machine.dev.
Promotional credits
Referral and open-source grants are available only to teams enabled or enrolled by Machine. A referral link or an open-source repository does not automatically enrol your team. Contact hello@machine.dev about programme availability.
Referrals
If referrals are enabled for your team, Settings → Referrals shows your signup link and referral statuses. Share that link before the new team signs up; there is no separate code-entry field.
Each eligible referral awards $25 to each team after the referred team installs the GitHub App and makes its first compute purchase within 90 days of signup. Settlement is processed periodically, so rewards may not appear immediately after payment. Referral grants expire 90 days after they are issued.
Self-referrals and teams sharing the same GitHub account or payment card are ineligible. A referring team can receive up to ten rewards. Negative balances prevent grants. A referral can appear as Waiting for first purchase, Rewarded $25, or Not eligible.
Open-source projects
Machine enrols eligible open-source projects individually. Enrolled projects receive a monthly compute grant, $20 by default, with the amount set for that project by Machine. Grants are issued once per UTC month and unused amounts expire at 00<00> UTC on the first of the next month. They do not roll over.
Spending and expiry
Promotional credit is part of your displayed balance and is spent before purchased balance, using the earliest-expiring grant first. The balance card shows the promotional amount and upcoming expiry. Unused credit is removed when it expires; an expiry can trigger the low-balance warning or auto top-up.
Promotional grants do not change your concurrency or runtime limits. A team funded only by free grants remains non-paying; a team that has bought compute retains its paid limits.
Next steps
- Spend analysis: identify expensive workflows, branches and commits
- Spot runners & savings: control cost and interruption risk
- Team management: billing permissions and team roles