Using the dashboard

The dashboard at app.bugmole.com is where you explore an app, run its tests and follow what broke. The header shows which workspace and project you're in. App and environment pickers appear once a project has more than one of either.

Overview

A new project opens with Paste your app's address: enter a URL and choose Explore this URL. Bugmole explores the app, turns each flow it finds into a test, and shows what fails when you run them. See Discover and debug.

Once a project has results, Overview leads with the answer to "can we release?": Don't release, Release with known risk or Ready to release, with the first reason. See Can we release? for what each one means. Below it:

• Coverage: the share of tests whose latest run passed (or of test cases, when the project has written cases), with the count in words ("1 of 10 tests passes") and what the rest are: failing, can't run, or never run. The percentage is red below 50%, amber from 50% to 79% and green from 80%. What counts? explains it, and the gap count jumps to the list below.
• Pages in graph, Needs attention (blocked steps and setup gaps, amber when there are any) and Last run (green when it passed, red when it failed, amber when it was cancelled or blocked).
• What isn't covered yet: the first three gaps Bugmole can see, and Show all for the rest: pages and journeys with no tests, tests never run, tests whose latest run failed or was blocked, journeys whose test cases were all retired, and what exploration couldn't reach (a sign-in page, pages that didn't open, skipped links). Each one has a next step, such as Run it or Set up sign-in for runs. How Bugmole found these explains where tests come from; see How Bugmole finds what to test.
• Last exploration: one line once an exploration has finished, with Run the flows and Explore again.
• Journey graph: a map of your app, each page once, left to right from where flows start, with an arrow for each step a flow takes. Highlight a flow picks out one flow's path, and By flow shows each flow on its own row.

Step status

Every step in the journey graph shows its status, and a legend above the graph explains each one:

Hover a step, or open it, for the reason behind its status.

Release report

Release report (from Coverage on Overview, or /report) answers "can we release?" from the evidence. It shows every test case, or every test if your project has no written cases, as one square colored by its latest result: passed, failed, couldn't run (a sign-in, a setup step or the app got in the way), or not run yet. Failures come first. It also counts each result and shows how much has been executed.

Below the grid, Bugmole recommends one of the verdicts in Can we release?.

Each reason links to where to act on it. Print or save as PDF prints the report on its own page for sharing. The recommendation only covers what Bugmole has evidence for: what no exploration or test case reaches isn't in it.

Can we release?

Overview and the release report give the same verdict, decided in this order:

A cancelled run doesn't count: the verdict uses the test's run before it. The verdict only covers what Bugmole has evidence for, so a part of your app that no exploration or test reaches can't make it worse.

Boards

Runs, Agent tasks and Issues are boards: a column per status, and a card per item. Every card shows, in the same places:

• its type: Run, Task, Test case, Issue or Audit finding, each with its own icon and colour;
• its status;
• its owner: the machine or Bugmole Cloud that holds it, or Unassigned;
• one next action, such as Approve, Resume, Retry, Open evidence, Ask the agent or Open in GitHub.

A line under each page's heading says what its cards are. A long column shows its first few cards; Show more lists the rest.

Tests

Every test in the project, named after the flow it runs, with how many steps it has. Select one to see:

• its path through the journey graph;
• Show the test file: the plan and flow Bugmole runs, to read, copy or download;
• its recent runs, and Run tests on the browsers, devices and environments you pick.

The line under the run button says where runs go (Bugmole Cloud or your own machines). Before you start, it says how long the selected test usually takes (from its own recent runs, or its step count when it hasn't run yet). While a run is going, it says roughly when it will be done. Explore this URL says how long exploring usually takes, too.

Selecting a test case shows the steps it takes and what it checks. Each case is labelled Assumption (what Bugmole expects, not yet checked by a run, with its confidence and what it's based on) or Checked by a run. Only checked cases count toward coverage.

A test case with more than one recorded result shows its last ten, newest first, and a Flaky badge when it both passed and failed among them. Flaky cases are listed first. Blocked results don't count as passes or failures, and each revision of a case has its own results.

Changing a test case

Select a test case and choose Propose a change to this test to edit its title, steps and checks, or propose retiring it. Agents propose changes through Bugmole MCP, and developers with bugmole propose.

Proposals wait under Proposed changes with a before/after of what they change, and a workspace owner or admin accepts or rejects them. In Extreme approval mode they're accepted on arrival.

An accepted change never edits the test in place. It becomes the next revision (shown as "revision 2"), and the one it replaces becomes obsolete. Obsolete revisions don't run or count toward coverage, and keep their past results; Show obsolete lists them. A new revision counts as untested until a run proves it.

Jira tickets

When the project is connected to Jira (Settings → Jira), the Tests page has a Jira tickets panel:

• Propose test plan to Jira posts the waiting proposals as one Jira task for review.
• Create tickets for approved tests makes sure every accepted test has a ticket. Tickets are also created automatically when a proposal is accepted.
• Also ticket existing tests does the same for tests that were in the project before Jira was connected.

Each test case with a ticket shows its key (like QA-12), linking to the ticket. Linked tickets lists them all with their latest result. Runs move tickets to Done or Blocked. A comment that mentions Bugmole on a ticket retests just that test. See Jira and project management tools.

Runs

Every run the project keeps, on a board with Queued and running, Needs attention (failed, partly passed, or couldn't test), Passed and Cancelled columns:

• each card shows when it ran, its steps, how long it took, and where it came from: the dashboard, a pull request or a commit, with a link to the GitHub check it reported to;
• Retry runs the same test again on the same environment and browsers;
• Cancel run on a queued or running run stops it: a queued run never starts, and a running one stops at its worker's next update (within about 30 seconds), whether it runs on your machine or on Bugmole Cloud. The run moves to Cancelled with who cancelled it. A cancelled run doesn't count as a failure: coverage, blockers and the release report use the test's run before it. Cancel run is also on the recent runs under Tests;
• By test: each test's last ten results, its pass rate, and a Flaky badge when it both passed and failed recently.
• Open evidence on a run opens each browser's result: screenshots, logs, trace and AI analysis.

A GitHub check's Details link opens its run here. How long runs are kept depends on your plan; see Plans and limits.

Issues

One place for what needs attention, in three tabs:

• Blockers: what stops Bugmole from testing a step, such as a login it has no account for or a page that won't load. They sit on a board: Stops the run, Needs setup and Answered. Ask the agent queues an investigation task for a blocker; once one exists the card links to it. Archive hides a stale card for everyone on the project; it comes back if the problem happens again.
• Visual bugs: where a screen differs from its design reference. The tab appears once a project compares screens with a reference.
• Linked: bugs linked to an issue in GitHub, GitLab or Jira, or a Trello card, on a board with Open, Closed and Unknown (the tracker hasn't reported a state) columns. Each card carries its tracker's logo, and the top of the page shows which trackers this project has connected. See GitHub App integration.

Devices

The browsers and devices your tests run on, and the sessions using them. See Real devices and device clouds.

Advanced

Folded by default, and opens on its own pages:

• Agent tasks: work queued for an AI coding agent or a worker, such as an exploration or a fix. Each task shows roughly when it will be done once it's running. See Approving agent tasks and Reviewing finished tasks.
• App Audit: checks every control on a screen, captures your app's design DNA (colours, sizes, spacing) and compares screens against a reference.

Approving agent tasks

Each project has an approval mode, set under the task form on Agent tasks:

A task that's waiting sits in Queued with Approve on its card; once approved it moves to Approved, where a worker picks it up, then Working. Each approved task says who approved it, or that the project's mode did. Only workspace owners and admins can approve tasks and change the mode.

An exploration held back by Manual mode says so on Overview, with Approve and start.

A worker can be stricter than its project: bugmole serve --approval manual only takes tasks a person approved. See the CLI reference.

Reviewing finished tasks

When an AI worker says it finished a task, the same approval mode decides whether a person looks at the work before it counts as completed:

A task waiting for review sits in In review, between Working and Completed, with the worker's summary and two buttons:

• Accept completes it. The card then says who accepted it.
• Send back asks what needs to change. The task goes back to Approved with your note (its approval stands), and the agent that picks it up next gets your note with the task.

Only workspace owners and admins review tasks; an agent or API key can't accept its own work. Both actions are in the audit log. Tasks that finished before review existed stay completed. While a task is in review, the automatic pipeline waits for it instead of building on unreviewed work, and nothing counts down on the card.

Why review follows the approval mode

We compared completing AI tasks automatically with always requiring a person.

One setting per project is easier to reason about than two: if you trust agents to start code changes by themselves (Extreme), you trust them to finish them; if you want to approve every task before it starts (Manual), you want to see every result too.

Where agent tasks run

Only explorations can run on Bugmole Cloud. Every other task (code, UI and investigation tasks, and explorations started for your own workers) runs on a machine running npx bugmole serve, or a coding agent connected through the Bugmole MCP.

• A queued task that runs on your machine while no machine is connected says Waiting for your machine, with how to start one, instead of an estimate.
• Resume puts a blocked or failed task back in the queue. A cloud task starts again straight away. On a project that runs in the cloud (Bugmole storage, or Bugmole Cloud by default), a task that needs your machine can't be resumed until a machine is connected: the button says Runs on your machine — start npx bugmole serve to pick this up. An exploration there offers Resume on Bugmole Cloud instead.
• A resumed task keeps a person's approval. One the project's mode approved goes through the current mode again, so in Manual mode it waits in Queued for approval.

Paused projects

On Free, a project nobody has used for 30 days is paused: no runs, agent tasks, exploration, CLI or MCP calls from a machine, or changes in the dashboard. It's marked Paused in the project picker, and the project shows Paused — no activity for a while with an Activate button. While paused you can open everything in it, but it doesn't run tests or tasks, and it doesn't count toward your plan's projects. Any member who can edit the project can activate it; if the workspace already has as many active projects as the plan includes, activating says so and links to plans. See Plans and limits.

Sign-in for runs

Settings → Sign-in for runs holds a project's sign-in flow and the secrets it types, so Bugmole Cloud can explore what's behind your sign-in page. Project owners and admins edit the flow in a text box and add, replace or delete secrets; each value is typed into a password field and never shown again. Each secret shows set • updated … by … and when a run last used it. The flow notes any secret it uses that isn't set yet. See Sign-in for runs for the security design.

Your account menu

• Profile & security
• Settings (the Manage Bugmole page): workspaces, projects, apps, environments, members, domains, roles, personas, alerts, GitHub and GitLab checks, Jira, device clouds, single sign-on and the audit log.
• Billing & usage, with the AI credits you have left.
• API keys
• Help: How Bugmole finds tests (see How Bugmole finds what to test), What the words mean (a glossary of every term the dashboard uses), Report a bug, Send feedback and My reports.
• Sign out

Leaving and deleting

On Settings, each item's edit page has the way out:

• Delete app deletes an app and its environments. The project's default app, and its only app, can't be deleted.
• Delete environment deletes an environment and the secrets set only for it. A project's last environment can be deleted too: runs then start at the URL in each flow. An environment that GitHub, GitLab or Jira runs use can't be deleted until they use another one.
• Delete project (owners and admins of the workspace): type the project ID under Type the project ID to confirm. Its runs in progress are cancelled, and its tests, runs, evidence in Bugmole storage, apps, environments, secrets and integrations are deleted, for everyone. API keys made only for the project stop working. Files a project keeps on your own storage are yours to delete. This can't be undone; the workspace's audit log keeps a project.deleted entry.
• Leave workspace: you lose access to its projects. Its last owner can't leave; make someone else an owner first, or delete the workspace.
• Delete workspace (owners): type the workspace ID under Type the workspace ID to confirm. Delete its projects first, and cancel its paid plan (a complimentary plan doesn't matter).

When results live on your machine

A project can keep its results on your computer instead of in Bugmole. Its pages then say Waiting for your machine until bugmole serve is running and you've opened the link it prints, including everything after #. See Getting started.