How much time is mabl saving your team, and where is that value showing up? The account-level value dashboard answers those questions by aggregating activity from mabl’s intelligent features across every workspace in your account.
Use this dashboard to see how often auto-heal kept tests running, how much of your authoring is happening with AI, and how often mabl investigated failures on your behalf. Then use the workspace table to understand these metrics across teams.
Accessing the dashboard
The account-level value dashboard is only accessible to workspace owners with account admin permissions. To open it, expand the workspace dropdown and click on your company dashboard:
From the account dashboard, select the Value tab in the left-hand navigation.
To get access, ask an existing account admin in your organization to add you. Admins can be assigned from the Billing tab of the account dashboard.
Filtering
To focus on specific workspaces or time periods, expand the Filters section and apply filters as needed:
- Workspace: By default, all workspaces in the account are included. Filter by workspace to review value metrics for a specific workspace.
- Date range: Select a time period for historical data. The default is 30 days, and you can view up to 100 days of data.
Each tile shows a total for the selected window and a daily chart so you can spot changes in activity.
Measuring value
The value dashboard measures the following:
| Tile | Description |
|---|---|
| Auto-heals applied | The number of times auto-heal recovered an element with an updated selector. mabl uses the healed selector on subsequent runs unless you reject it. |
| Visual assertions executed | Visual assertion steps evaluated during test runs. Visual assertions validate page content using generative AI based on a natural-language description. |
| Visual finds executed | Visual find lookups executed during test runs. Visual find targets elements using a natural-language description — useful for highly visual elements like charts, maps, or icons that lack text-based attributes. |
| Retries recovered | Test runs that initially failed and then passed on automatic retry inside a retry plan run. |
| Tests authored with AI | New browser tests whose first version was created with the help of the mabl agent. Mobile and API tests created from natural-language prompts aren’t currently counted. |
| Tests edited with AI | Browser tests that were edited by the mabl agent after their initial version. |
| Test runs analyzed with AI | Failed test runs that mabl analyzed. The analysis investigates the failure, gathers evidence, and submits a root-cause summary. |
| Plan runs analyzed with AI | Failed plan runs that mabl analyzed. The analysis summarizes failures across the plan’s test runs to surface common themes. |
| Deployments analyzed with AI | Failed deployments that mabl analyzed. The analysis investigates the failing plan runs and tests under a deployment to identify root causes. |
| Runtime recovery sessions | The number of times runtime recovery activated during a running test to recover from a failure. Each session represents an in-flight intervention that kept a test moving. |
Use the value dashboard to understand time saved on test maintenance and overall team adoption of AI-powered functionality:
- How is our team saving time on test maintenance? Review auto-heals, retries recovered, and runtime recovery sessions.
- Where are we using natural language to generate tests and test steps? Review visual assertions, visual find, and tests authored and edited with AI
- How many tests are authored with the mabl agent? Review tests authored and edited with AI.
- How often is mabl investigating failures for us? Review test runs, plan runs, and deployments analyzed with AI.
Workspace breakdown
The By workspace table beneath the tiles shows the same metrics with a row per workspace, plus a totals row. Click a workspace name to jump directly to that workspace’s dashboard.
Use this table to compare adoption across teams. For example:
- A workspace with high authoring counts but few analyses might have a confident, hands-on team
- A workspace with many analyses and few retries recovered might be a good candidate for a conversation about test stability.