mabl measures usage in two ways: credits for cloud test runs, and test authoring activity for categorizing users. This article explains how both are calculated, what counts toward your allocations, and what doesn’t. For information on how to review your usage in the mabl app, see:
- Reviewing workspace usage for your workspace’s usage page: Settings > Usage
- Account billing and usage for the account-level billing dashboard
- Credit allocations for how credits are distributed across workspaces
mabl Core plans only
This article describes billing for organizations on a mabl Core plan. If your organization purchased a legacy plan (startup, growth, or enterprise), your usage is measured by test type rather than credits.
Credits
Credits are the unit of measurement for tests executed in the mabl cloud. Your account is allocated a set number of credits, which are distributed across your workspaces.
Credit consumption
Credit consumption reflects the amount of cloud resources a test run consumes. The following table shows how many credits different test types use:
| Type of run | Credits consumed |
|---|---|
| Local mabl runs | 0 credits |
| mabl runs in your CI environment | 0 credits |
| Browser cloud run - desktop or mobile web |
Without visual assertions: 1 credit With visual assertions: 1.5 credits |
| Mobile cloud run |
Without visual assertions: 5 credits With visual assertions: 5.5 credits |
| API cloud run | 0.1 credit |
| Visual test run | 1 credit |
| Performance run |
Credit consumption is based on duration, which is rounded up to the nearest 15-minute increment:
To determine the number of credits consumed, multiply the number of billable VUH shown on the test details page by 4. Billable VUH represents the total number of billable virtual user hours (VUH), billed in 15 minute increments. |
| Local Playwright runs |
Without visual assertions: 0 credits With visual assertions: 0.5 credits for every 6 visual assertions. Credit consumption is calculated on a daily basis and rounded up to the nearest half-credit increment. |
What doesn’t consume credits
The following activities do not consume credits:
- Local runs: running tests locally on your machine or via CLI
- GenAI test creation and step generation: creating tests with the Test Creation Agent is part of the advanced AI add-on and does not consume credits
- Failure summaries: AI-generated failure summaries are part of the advanced AI add-on and do not consume credits
- Visual assertions in local/CLI runs: visual assertions only consume additional credits when run in the cloud
- Mobile cloud training: although mobile cloud training sessions use cloud resources, they are not test executions and do not consume credits
Test authoring activity
Test authoring activity measures how users interact with tests in mabl. Your account is allocated a set number of users, and each user’s level of test authoring activity determines how they are categorized for billing purposes.
What counts as test authoring activity
The following actions count as test authoring activities:
- Creating a new test or duplicating an existing test
- Saving a new version of an existing test
- Deleting a test or restoring a test from the activity feed
The following actions do not count as test authoring activities:
- Test metadata: updates to names, descriptions, labels, device settings, or test case IDs
- Reusable components: changes to flows, snippets, DataTables, credentials, or file uploads
- Infrastructure and workspace settings: modifications to applications, environments, branches, plans, or permanent email addresses
Test authoring activity is tracked per workspace. If a user belongs to multiple workspaces, their activity in each workspace is measured separately.
Automators and participants
Based on their monthly test authoring activity, users are categorized into one of two groups:
- Automators: users with 30 or more test authoring activities in a single workspace during a given month.
- Participants: users with fewer than 30 test authoring activities in every workspace during a given month.
These categories are defined on a monthly basis. At the start of each month, all users begin as participants. When a user performs 30 or more test authoring activities in a workspace during the month, they become an automator for that month. A user may be an automator one month and a participant the next, depending on their workload.
A user who belongs to multiple workspaces is an automator if they reach 30 activities in any single workspace. For example, if a user performs 24 activities in Workspace A and 12 in Workspace B, they are a participant, even though their combined total is 36, because they did not reach 30 in either workspace. If they performed 31 activities in Workspace A and 5 in Workspace B, they would be an automator based on their activity in Workspace A.
For details on how user status is determined at the account level, see Account billing and usage.
How workspace roles relate to automators and participants
Every user in a workspace, whether they have a viewer, editor, or owner role, is counted as either an automator or a participant. These are separate concepts:
- Workspace roles (viewer, editor, owner) determine what a user can do in the workspace.
- Automator and participant status reflects how much test authoring activity a user performs.
Because viewers cannot create, save, or delete tests, they cannot accumulate test authoring activities. Viewers are always participants.
Active users vs. total user count
The Active users table on the usage page shows users who performed at least one test authoring activity during the selected time period. Users with 0 test authoring activities are still counted as participants in the total user count but do not appear in this table.
For example, if your account has 30 total users (3 automators and 27 participants), the Active users table may show fewer than 30 users because it excludes participants who had no test authoring activity.
Billing period
Credits are allocated on an annual basis. Your account receives a set number of credits for the year, giving you flexibility to run tests when you need them without estimating usage on a monthly basis.
Unused credits do not roll over to the next billing period. At the end of the year, your credit balance resets.
You can find your account’s billing period and contract duration in the Account users section of the account billing dashboard.
Exceeding allocations
Exceeding your allocated number of credits or users does not block usage.
- Credits: the total number of credits is distributed across all workspaces. Workspace credit allocations are a suggested guideline, not a hard limit.
- Users: you can invite an unlimited number of users to your workspace. If your workspace exceeds the total number of allocated automators, mabl will not prevent participants from becoming automators. mabl licenses are not named licenses. Anyone can be an automator or participant in a given month based on their test authoring activities for that month.
If your account consistently exceeds its allocations, please work with your customer success manager (CSM), or your account executive (AE) will reach out to discuss adjusting your plan. If you do not know who to reach out to, email support@mabl.com.