Dashboard guide

Getting in

The sign-in screen is one screen with several states. Which one you are on is named at the top.

A second factor is required on every account, not offered. Use a different email backs out of a half-finished enrolment.

Outside production there is also Explore with sample data →, which opens the dashboard on a demo workspace.

An invitation

An invite email lands on a page that tells you what you are being invited to — who invited you, the address it was issued to and your role — before it asks you to sign in. The terms first, the sign-in underneath, because asking somebody to sign in before telling them what for is how invitations get ignored.

Accepting needs a session either way, and the address you sign in with has to match the address the invite was issued to.

SSO

If your workspace has SSO configured for your email domain, sign-in hands you to your identity provider instead. See SSO.

Two factor, later

Settings → My Account → Profile carries the two-factor panel. There is no "turn this off": the only things it can do are move the factor to a different phone and reissue the recovery codes. Both ask for your password again — a session lifted off a machine must not be able to re-point the second factor at a phone its holder owns.

The shell around every screen

The sidebar

Workspace switcher at the top: the workspace mark, its name, its plan and your role in it. If you belong to more than one, the menu lists them all.

Then, in order:

There is deliberately no Reviews entry. A review is not a place you go: it arrives in front of the dashboard when there is one. /reviews still exists and the bell links to it.

Team is hidden from members rather than shown and refused — a nav entry that leads to a refusal advertises to somebody that there is a screen about them they are not allowed to see.

Below 820px the sidebar becomes a drawer; the burger opens it and any navigation closes it — otherwise you land on a page you cannot see.

The topbar

⌘K — the command palette

The answer to "I know what I want and I do not know which screen it is on". It holds two kinds of thing: places, matched in the browser, and bugs, searched on the server through exactly the same route the queue uses — so it obeys the same project-visibility rules. Type a screen name, a project, or anything from a bug's title, description, URL or id.

The phone

Mounted once for the whole dashboard, not on the bug page — because somebody three screens away in Analytics is exactly who might be free, and a phone that only rings in the room you are already standing in is not a phone.

• Incoming. A reporter can ring about a report they filed. It rings everybody who can see the report, not its assignee, and whoever is free answers.
• Outgoing. A member can ring the reporter back. The button is on the report — that is where you decide you want to talk to somebody — and the call is held here, so walking off to look at the queue while it connects does not drop it.

Settings → My Account → Profile has the ringtone picker. It is per browser, not per account: the same person at a different desk gets the default back. Every row plays when you pick it, because four ringtones described in words are four descriptions of "a ringing sound".

Things that appear on their own

Roles: who can do what

Four roles. The API is the enforcement point; the dashboard hides what you cannot do rather than letting you click it and take a 403.

What each action needs:

Who may change one particular bug

Separate from the role, and this catches people out. The role is the floor: a viewer never edits. Above that, a bug belongs to the people named on it.

• A member may change a bug they are the assignee of, or that has been escalated to them, and no other.
• Admins and owners may change any bug.
• A member opening an unowned bug is asked whether they want to take it. Opening a report does not claim it.
• A member opening somebody else's bug gets a locked banner: they can read everything and follow the thread, and changing it is the owner's to do.

The queue

The dashboard's home screen: the reports in the selected project (or across all of them), in whatever slice the sidebar and toolbar describe.

Every filter lives in the URL. That is the design rather than a detail: a filtered queue is a link somebody can paste into a thread, so "the unassigned criticals" becomes a thing a team points at instead of a thing each member reassembles by hand. It is also what a saved view is.

Filtering, searching, sorting and paging all happen on the server, over the whole queue.

The toolbar

The filter chips

all severities, then critical / high / medium / low — click one to filter, click it again to clear.

save view appears as soon as any filter is on. It asks for a name and puts the view in your sidebar. A saved view keeps the span name rather than its dates, so a view called "today" means the day it is opened.

On the right: how many bugs matched, the page you are on, and — when it applies — searched the most recent N. That last part is said out loud rather than implied: a search that opened the most recent 2,000 reports and found nine is a different claim from one that read everything.

The rows

Both views show the id, the title, the severity spine, the status badge, the origin line (host and age), and the project key when you are looking at all projects.

Two things on the title line are worth knowing:

• ⇧ escalated to you — only on your own rows, and on the title line rather than in the assignee column, because the column is one of the ones a phone hides. A bug escalated to you must not look like a bug that is somebody else's.
• In the list view the assignee column shows both owners — the assignee and, under it, the escalated name. A column showing only the first read "this is Priya's" about a bug handed to somebody else hours ago.

Selecting and acting in bulk

Tick rows (or the header checkbox for the page) and a bar appears above the list, so it never covers the rows it is about to change.

Deleting is deliberately not on the bar. It is the one bulk action whose mistake cannot be corrected from this screen, and forty reports removed by a mis-click is not a thing to make convenient. Messaging is a button that opens a dialog rather than a control that acts, for the same reason: a sent message cannot be unsent either.

Keyboard

What the empty and broken states mean

The queue updates itself: every change to a bug arrives as a live event. When the live stream is down it falls back to re-asking every 20 seconds, because a queue that has quietly stopped moving looks exactly like a quiet morning.

A report

Two columns: the evidence on the left, the decisions on the right.

The header

← back to queue, then: copy link, download attachment (when there is one), and delete (admin and above).

The banners

The left column — the evidence

The media viewer at the top: screenshots, video, audio and files captured with the report, as a strip when there are several, each with download it. A report with nothing attached says no screenshot or recording was attached to this report rather than showing a broken frame.

An attachment can carry a transcript. Where there is none the panel says which of three things is true — this screenshot has not been read yet, transcription failed, or there was nothing to transcribe. A single "nothing here" would read as "this screenshot has no text in it" in all three cases, and it is only true in one of them.

Then five tabs. Console and Network carry a count.

The right column — the decisions

The panels are in the order they are, deliberately: what is concluded above what is still a question, and the conversation above the fields, because what a report needs from you is almost always in what was last said on it.

Summary

The id, the severity tag, the title, the page it happened on, when it was reported, and the reporter's description.

AI analysis sits inside it, when the workspace has a provider configured:

• The summary, as points.
• Likely cause — labelled inline as a hypothesis and left visible, because for somebody triaging it is the most useful thing on the panel. It cannot lose the hedge: a confident wrong cause costs more time than no cause at all.
• Steps to reproduce (N), folded.
• A suggested severity and suggested tags, which you can apply.

On a report that has not been analysed the panel offers Analyze now, which queues a run — the button then reads Analysing… and stays that way until the result arrives over the live stream, which is the same path an automatic run takes.

On a report that has been analysed there is no re-run button and no model id. Neither belongs to the reader: the model is a workspace setting chosen once and meaningless to somebody triaging, and a re-run is a job the product already does for every report that arrives — offering it per bug turned an automatic step into a decision, and spent the workspace's provider credit to mostly reprint what was already on screen.

Where no key is configured the panel says no AI analysis — this workspace has not configured a key yet and points at AI Provider. Where the plan does not include analysis, or the reader cannot reach that screen, it says that instead.

Root cause & solution

What the team concluded. Renders nothing on an open bug with nothing written — a permanent empty "root cause" box on every report in the queue would be a reminder of a form nobody has reached yet. On a settled bug with nothing recorded it prompts instead, because there the absence is the story: the bug is finished and nobody said why.

The two fields are root cause and solution. Where one was left blank it says not recorded; where the team explicitly established none it says nobody established one, which is a different and honest answer. A write-up by somebody who has since left the workspace is marked as such, so nobody wastes an afternoon looking for them.

Editing it re-writes the knowledge-base note as well as the bug. A correction that only changed the bug would leave the note stating a cause the team has since retracted, still retrieving and still reading as authoritative.

Estimate

How long this is likely to take, folded away until asked for — a prediction is not what anybody opens a report to read.

It always names what it rests on, because the four are not the same claim:

Nothing at all on a settled bug: the question stops being asked the moment it is answered.

Possible duplicates

Suggested repeats, when there are any — nothing at all when there are none. Each one says how long the original took, which is the half of "we have seen this before" anybody actually wants: the same problem solved in a day is a different decision from one that took three weeks.

Accepting closes this bug in favour of the older one, so the two actions are worded as a decision rather than a dismissal.

Checked against your data

What an analysis found when it looked in the systems this project connected. Nothing at all unless there is a finding.

The evidence list is the part worth reading twice: it names the tools that actually ran and which connection each ran on, cross-checked server-side against the model's own account. A claim sourced from the repository and a claim sourced from the production database are worth different amounts of trust, and you are the one who should weigh that.

Connections are set up under Trackers & Data Sources.

Pipeline

What the system did to this report, and what it did not do. Always folded, on a healthy report and a broken one alike — but the badge in its header is rendered whether or not it is open: 2 failed, 1 skipped in the warning colour is the signal, and opening it is how you find out which two and why.

Failures and skips come first and read without a second click; the successes fold behind a count. This is the panel to open when another one is thin and you want to know why.

Suggestions

What the knowledge base believes the team has already fixed. The search runs when the bug is filed, not when you open it.

It renders whichever of three things is true — an answer, a search still running (looking for more…), or a search that came back empty — and takes all three from the server rather than guessing, because rows alone cannot tell "no past fix matches this" from "we have not finished looking".

Each suggestion says drawn from: which past reports it came from, so the claim can be checked rather than taken on trust.

Live call

Renders only while a call about this report is happening, or just was — above the triage fields, because somebody speaking about this report right now outranks every control below it.

Each line appears as it is recognised. The durable copy arrives in the conversation below as a message when the call ends.

Take this call is the one thing here that acts: whoever steps forward should own what comes out of it, and on a report that opened as a call there is nobody to own it yet. It makes the same ordinary assignment, with the same audit row, that the claim prompt does.

Conversation

Two tabs.

Thread is the team's and the reporter's messages together — bubbles with a side, team on the right, reporter on the left — with the triage events between them as quiet centred lines.

• Type @ to mention a colleague.
• Attach up to 6 files per message, 25MB each; you can paste one straight into the box.
• Draft a reply with AI writes a first draft you edit before it goes.
• Each message says plainly who will see it. Whether the composer starts on "customer reply" or on an internal note is a per-project setting — Project → General.
• A message that went out automatically is labelled as such, in your thread and in the reporter's. That label is not a convenience: whoever inherits this conversation must not answer the next message believing a colleague already handled this one.
• An AI draft is marked drafted — read before sending, and a draft written before the newest message says written before the latest message rather than letting you send a reply to a question that has moved on.
• A reply the reporter rated badly is marked marked as the wrong answer, with what they said was wrong with it.

Email the customer shows the rendered email before you send it, so nobody sends a template they have not read. Most of these send themselves when the status changes; the panel says whether that already happened or will. The main case it is still needed for is an address the reporter never confirmed, which is deliberately never mailed automatically.

Sending needs both halves: your role must allow emailing a customer, and this bug must be yours to answer for.

Reported by

Who filed it and the two ways of reaching them, cheapest first. A reporter your own application identified through the SDK is marked identified by your app through the SDK, which is a stronger claim than an address somebody typed.

• The identity card: name, address, and how many reports they have filed before. A report on its fourth visit from the same customer opens a call differently from a stranger's first.
• Whether the address was ever confirmed — an unconfirmed address is never written to automatically.
• Call — available for about as long as they keep the tab open, which is why reachability is asked rather than assumed.

Details

Changes save automatically. The line under the fields says whether you may make them.

The close dialog

Opened by moving the status to Resolved or Closed, and it sends the status change itself — Confirm is the button that closes the bug, and Cancel leaves the status where it was.

That ordering is load-bearing. A dialog that appeared after the status had already moved would be a survey, and a survey attached to a job that is already finished gets dismissed.

It asks two things, seeded from anything already on the bug so a reopened-and-re-closed report is a correction rather than a blank page:

• Why it actually broke. The box asks you to name the file, endpoint, header, config key or query — and says outright that "a caching issue" helps nobody.
• What you did about it, and anything the next person should check first. Whether it

asks at all, and whether an answer is required, is per project: Project → Resolutions. The requirement is on the pair, never on each field: "we never established why, we just rolled the deploy back" is a real close and an honest one, and a form that refuses it teaches people to type "n/a".

Known issue

Whether this report is named in the widget's known-issues list, and who has said it is happening to them too.

There is no "publish" control, deliberately. A report reaches the list on its own once a second person has hit it — by filing a report matched to this one, or by pressing "this is happening to me too" in the widget. The manual version asked somebody to notice a repeat, remember this panel existed and come back to an older report to tick a box.

What is left is a takedown, and only that. Publishing on evidence is safe to automate because the evidence is two people rather than a judgement; unpublishing is a correction only a person can make — a title that reads fine to the team and wrong to the public is a thing no rule can see.

Needs the feature switched on for the project: Project → General.

Share

The link to this session, and who it works for.

The project's own default is under Project → Access.

Tags

Add one and press Enter; × removes it. Tags feed the Most common tags chart on Analytics, and an assignment rule can match on one.

Conversations

Every conversation this workspace has had, gathered by the person rather than by the report.

The thread on a bug answers "what was said about this report". This answers the question the bug view cannot: what have we said to this customer — which until now was spread across one thread per report and one queue per project. Somebody who has filed into five projects had five conversations here and one in their own memory, and only one of those is the relationship.

The left column is people, one row each however many projects they span. Every message inside carries the report and the project it belongs to. Search across people and projects at the top.

Read-only, deliberately and visibly. There is no composer, and the header says why: replying belongs on the report, where the reply has a subject, a status and a reporter to notify. A box here would have to guess which of five open reports an answer was about, and would guess wrong exactly on the threads this screen exists to untangle.

Analytics

Opens on today, across every project — the question somebody actually walks up to it with — rather than on a shape averaged over the whole of a workspace's history, which is where a bad morning goes to hide.

The controls

• Scope: this workspace, or one project. The workspace option is disabled where there is no workspace to compare across, rather than claiming a scope the screen is not showing.
• Date range: today and the wider spans, plus specific dates — which reveals from date and to date. An impossible pair is refused with the reason rather than charted.
• Download CSV — the slice currently on screen.

With the API unreachable it says showing sample analytics rather than charting nothing.

Every figure names the span it counted, so an empty screen reads as "nothing today" rather than as a workspace with nothing in it.

The panels

The written summary

Generate insight writes a short read of the numbers. Pick what to analyse from three focuses:

The result comes back in three parts: what it found, risks, and suggested next. Needs an AI provider — Integrations → AI Provider.

Team

Admins and owners only.

Per-person figures for the workspace. It opens on 30 days, not today: a day is too short a window to say anything about a person — one report closed in the morning and a median has a sample of one — and a screen that opens on a sample too small to read invites a conclusion drawn from noise.

The table's columns carry a note each explaining what the value counts. Open now is what somebody is carrying today whatever range is picked above; everything else is measured over the range.

Nothing on this page is coloured by how well somebody is doing. Up to four people can be put side by side to compare, and team filters narrow by project and date range.

Alongside the per-person table:

Generate insight, email the report and download CSV are along the top. Filtering is by project and date range; everybody is the default.

Reviews

Whatever you have been asked for, and what is still outstanding.

Nothing on this screen depends on your role — the owner, an admin and a read-only seat all see the same thing, which is their own list. Composing a review, sending it and chasing it belong to BugCatch staff.

There is nothing to do on this page. Answering happens in the dialog the dashboard puts up, one at a time and mandatory first, and that dialog is already standing in front of this page whenever there is anything to answer. What this screen is for is the question the dialog cannot answer: what else is coming, and by when.

Projects

Creating one

The count against your plan's limit is shown; going over needs a plan that allows more.

Groups

A group is a heading on the projects list and nothing more — it does not change who can open a project. Create, rename and delete them here; assign a project to one here or in Project → General.

The list

Each project shows its bug counts, when it was last active, and its project ID with a copy button — that id is what goes into the browser extension's popup and the Web SDK snippet.

Projects are listed under their group headings. A project with no group sits under No group.

At the plan's project cap, the create form says so and offers See plans →; if you are not the owner it says to ask the workspace owner to lift it, because that is who can. With the API unreachable the page shows sample projects and says they are samples.

Settings

Four groups. Which entries you see depends on your role; the API enforces the same rule.

Pages that configure one project show a project bar above them. Pages that configure the workspace do not. The one page in the Integrations group that is project-scoped shows the bar anyway, so the difference is visible where it bites.

Project settings

General (project)

At the bottom: the Project ID and, where the knowledge base is on, the knowledge base ID, both with copy buttons. Then the danger zone — Delete project, owner only, which removes its bugs, attachments and integrations.

Access

Two independent switches, both enforced server-side.

Session visibility is the default a newly captured session inherits, which decides whether its share link works for outsiders. A session can override it — see Share.

Session visibility asks who can view your sessions by default? — the same Public / Private pair, marked with which is the default.

Below them, Project members: who can open a private project, with Add a workspace member… to bring somebody in. Changing either switch needs the admin role.

Members (project)

Who is on this project. Owners and admins administer every project by rule, so their access is not something this screen can narrow — the control is offered only for members and viewers, which mirrors the API rather than offering a control whose save would be refused.

Access is all-or-selected rather than a bare checklist, because an empty checklist cannot say whether projects created later should be included.

Automation

What this project may do to a report while nobody is watching. Per project, because a team runs its internal tool and its checkout to different standards. Everything is off until you turn it on, and every automatic change is signed in the bug's timeline by the thing that made it.

From the analysis

Who it goes to — assignment rules. Tried in order, first match wins. A rule with no conditions matches everything, so keep that one last. A rule that matches but names nobody stops the search — which is how you say "leave these alone". Each rule has a name, an optional tag, an optional "URL contains", and who it assigns to. Rules can be reordered.

Under them: hand anything no rule matched to whoever is holding the least, counted across the people who can actually open this project and only their open bugs here. The floor under the rules, not a replacement for them.

How long a report may wait — a response and a resolution target per severity. A missed target escalates the bug to an owner or admin and shows up in the summary email. Blank means no promise, which is the honest setting for most teams on most severities. Write minutes, or 4h, or 2d. Response targets are measured from the first reply a member sends the reporter.

When the reporter goes quiet

Repeats — file a report against the one it repeats. Nothing is merged, closed or hidden: both reports stay in the queue with their own conversation. What the link buys is that when the original is fixed, everyone who reported it is told. Only above this confidence (60–100) sits well above the 55 a suggestion is stored at: a weak suggestion costs somebody a dismissal; a weak link quietly promises a customer an answer to another problem.

From your tracker — let a closed issue resolve the bug here. When the Jira, GitHub or Linear issue this bug was pushed to closes, the report is resolved, the knowledge base learns the fix, and the reporter is told, without anyone opening the dashboard. Needs the webhook set up under Integrations.

Whether any of it is running — the scheduled sweeps and when each last ran. Everything above happens on a schedule, and a schedule that stopped looks exactly like a week with nothing to do. This is the difference. It refreshes itself every 30 seconds, so it can be left open while you wait for one.

Automation is a plan feature. On a plan without it you can set all of it up and nothing runs.

Resolutions

What this project asks of a close, and what it does with the answer.

Project-scoped, unlike Knowledge Base, and the split is the point: that screen owns the connection — one tenant, one key, one master switch for the workspace — and this owns the policy, which is obviously right for a support queue and obviously wrong for an internal backlog in the same account.

The three groups are closing a bug, the knowledge base, and telling people how long it will take — so the page reads as three decisions rather than six switches. The connection those middle switches depend on is Settings → Knowledge Base; this page only decides policy. Admin role.

Report identifiers

How this project recognises which record a report is about.

The identifier was nearly always in the report already — somebody typed "loan LN-2024-000481 is stuck on disbursal" into the box, and nothing read it. This is the screen that makes it a field.

Per project, because what counts as an identifier is a fact about your product rather than about BugCatch. The defaults are a lender's — loans, partners, two phone numbers per borrower — and are meant to be rewritten.

Two switches decide when the field is used: read this out of the report's own text — which is the whole point, since the identifier is usually already in what somebody typed — and what to do when a report carries nothing identifying. A field that satisfies that policy is marked this one satisfies the policy above, so you can see at a glance whether the project can actually identify a record.

Try it on a real report runs the extraction against something already in the queue, which is the only honest test of a pattern.

What is captured appears at the top of the report's Info tab, and a data source can join on it — see Trackers & Data Sources. Admin role.

Recording link

A URL that lets somebody outside your team file into this project with no account — beta testers, a client, a support agent on another system.

Create link takes a name — who is this for? e.g. Beta testers. Each link in the list carries its status and a revoke. The token in the URL is the credential and it only ever files into the one project it names.

A project with none says so: creating one is how you collect reports from outside your team. Managing links needs the admin role. What the person on the other end sees is A recording link.

Web SDK

The install snippet for this project, with the project id already in it — which is why the page asks you to pick a project first rather than emitting a placeholder you are invited to copy.

What the SDK costs you, stated on the page: 4.2 kB gzipped, zero dependencies, Shadow DOM so it cannot collide with your CSS, and ring-buffered capture so its memory is bounded.

What gets captured — console, network and environment — and options are listed underneath. The snippet needs a key from Workspace Settings → API Keys.

Full reference: Web SDK docs.

Email template

What notifications from this project say. Admin role.

Pick which notification under Send this notification, then edit its subject and body. Insert: lists the variables you can drop in, Preview renders the result, and Reset to default puts the shipped template back.

Integrations

Everything this workspace is wired to. They used to be filed by which record owns them — a tracker under the project, a model key under the workspace — which is a rule that only makes sense to whoever wrote the schema. What somebody actually arrives holding is "this thing is not connected".

Trackers & Data Sources

One page, two directions.

Trackers push a report out when a rule fires: Jira, GitHub, Linear and Slack. Each takes its own fields plus a secret for verifying what comes back, and each connected one can be disconnected. Pair with let a closed issue resolve the bug here in Automation.

Data sources read a system back in when an analysis decides to look — your own product database behind a server you run, or the hosted server a tracker publishes. Add a data source takes:

A project with none says Nothing connected yet. Analyses run on the report alone — which is a working state, not a broken one.

What a data source produces shows up on a report as Checked against your data.

AI Provider

Which vendor this workspace reaches, on whose key, and which of its models answers.

This is the half of the AI settings that is a connection rather than a preference: a key buys access to a vendor and a model is a thing that vendor serves, so the two are on one card. This page writes the model and the key and nothing else, so an open tab of AI cannot undo a provider switch made here.

Pick the provider, then its model. Each model says what it costs, and one that costs nothing per analysis says no per-analysis cost rather than showing a zero.

With no workspace key the page says it is falling back to the server's key rather than appearing unconfigured. Remove stored key takes yours back out and returns to that fallback. For a self-hosted endpoint the key is issued by the endpoint itself — ask whoever operates it, which is the sentence that saves a support round trip.

Admin role.

Knowledge Base

Whether resolved bugs teach a knowledge base, and whether new reports are met with what it already knows.

Stored unencrypted. Resolution notes are written from bug titles, descriptions, logs and comments, and they are kept in plain text in sphoro.kb — outside this database. On a workspace that encrypts at rest, this content is not encrypted once it reaches the knowledge base. That is said in full above the switch rather than tucked behind it: the person deciding is entitled to know before the checkbox, not after.

The switches are grouped by what they touch: the status and tenant of the connection at the top, then learning and suggesting, then analytics, then answering reporters, and finally answering reporters automatically — which is fenced off from the rest because it is the only one that writes to a customer without a person reading it first.

The danger zone drops the copy that lives outside this database — the one in sphoro.kb, which deleting this workspace would not reach.

Voice Calls

Whether a reporter may ring the team instead of typing another message.

What leaves this database. Starting a call sends the report's reference, title, status, priority and project name to sphoro.voice, so whoever answers knows what it is about. The conversation itself goes nowhere — the audio is browser to browser — unless you switch on recording or transcription below, and then a speech vendor reads it in the clear. Off by default, per workspace, and written to the audit log when it moves.

Both keeping switches are off by default, and that is the point: there is no copy of a call anywhere unless you make one. Turning either on changes what the reporter is told on the card before they press Answer, which is the only honest moment to say it.

Everything the page cannot fix it says plainly — a deployment with no sphoro.voice configured is not a form to fill in but a sentence naming the variables somebody has to set on the API first. The one refusal it names up front, rather than letting you find it on a real call:

• Nothing will reach the thread — no webhook secret is configured, so the report gets no note, no duration, no recording and no transcript. The calls themselves work, which is exactly why it is worth knowing beforehand.

The page is laid out as status, calls to the team, what a call keeps, and how much it may cost — since calls are the one feature here with a per-minute price. Which sound your own browser makes when one rings is Profile → Ringtone.

Workspace settings

General (workspace)

Name, plan and identifiers for this workspace.

The workspace name (renaming needs the admin role — the page says so if you lack it), the Workspace ID with a copy button, and your role here.

The danger zone at the bottom deletes the workspace. Owner only.

Members

Invite, re-role and remove. Inviting needs the admin role.

Invite takes an address (teammate@company.com), a role, and — for a member or a viewer — which projects they may open: All projects or Selected projects. All-or-selected rather than a bare checklist, because an empty checklist cannot say whether projects created later should be included.

Pending invites are listed under the members, each with a revoke.

Transfer ownership is here, owner only. A workspace with no projects yet says so rather than offering an empty project picker.

AI

How the analysis behaves, once there is something to run it on. Which vendor and model is AI Provider; what is left here is every decision that survives changing your mind about the vendor.

The page opens by naming what is running — Running on <model> (<vendor>) — or, where there is no key, saying that bugs are skipped and nothing below runs.

Four sections:

Extra instructions (optional) at the bottom is free text — your stack, your conventions, what you want it to prefer: "Our stack is React + Rails. Prefer concrete file/function guesses over generic advice."

Admin role.

AI Usage

Where the AI bill actually goes, answered three ways because three different people ask it:

• Total for the month.
• What the calls were for — the breakdown that changes decisions, because it is what shows most of the spend going to one feature.
• Which models ran.
• The last N calls, one by one — up to 50 — each with its output and cached token counts, since a cached read is not priced like a fresh one.

Nothing here is estimated. Every row is a call that happened, priced from the same catalogue the model picker shows.

API Keys

The keys your site reports with. Admin and above.

Create key takes a name — what is this key for? e.g. Marketing site. The secret is shown once, with the warning that it will not be shown again; copy it then.

The table lists each key with when it was created and when it was last used — that second column is how you find the key nothing needs any more — and a Revoke on each.

With no keys, the page says so and points at what one is for: creating one is how you start reporting from your site. Full reference: REST API docs.

SSO

Owner only.

Three switches sit over it: Enable SSO turns it on, Require SSO stops password sign-in for that domain entirely, and Remove SSO deletes the configuration.

Audit Logs

Who did what, when. Filter by action, or leave it on All actions.

It includes actions taken by BugCatch staff on your workspace — that is the only trace you see of them. A workspace where nothing has happened yet says Nothing recorded yet rather than showing an empty table. Admin and above.

Security (via Regex)

Redaction rules applied to captured content before it is stored. Owner only.

Credential scrubbing is always on. These rules are in addition to the built-in scrubbing, not a replacement for it — you are not switching redaction on, you are adding your own patterns to it.

Start from: offers a template rather than a blank regex box. Try it against a sample runs the rule in front of you before you save it — write the rule, paste a real line, see what survives. Each rule in the list carries its scope, its status, and a delete.

A workspace with none says No redaction rules — which means the built-in credential scrubbing is all that is running.

Encryption

Read-only, on the Security screen: what is encrypted at rest, and where to change it. Encryption follows the plan, and the plan is agreed with an account manager who either sets it or issues a code — it is not a switch here, because a confirm() dialog is not enough between one click and every content row in the workspace being rewritten to plain text.

My account

Profile

Your account across every workspace you belong to, not just this one.

At the top: your name, your email, and a Platform administrator tag if you are one. Then your User ID, the current workspace, and your role here.

Changing your name, email or password is not wired yet — the API has no profile-update route, and the page says so rather than offering a form that does nothing. Your authenticator and recovery codes are managed here; everything else about the account is not yet editable.

Plans and Usage

Owner only (and BugCatch staff).

Current plan at the top, then the meters:

Mobile app sits in its own block above the bill, because it is the one number on this screen you can change from here. The price is quoted against the members the workspace actually has rather than per seat in the abstract — "$5 / member" is a rate somebody has to multiply, and the whole point of doing it here is that the count is already known. Only an admin or the owner can change it.

Then the bill: at today's usage, per month at the monthly rate, and past months, measured when each month closed rather than recomputed — so a closed month does not move. If the closed months cannot be fetched the page says that, rather than showing nothing.

Changing plan is not done here — see Plans and pricing.

Deleted Sessions

Bugs you delete from the queue wait here rather than disappearing, with the project they came from and when they were deleted. Restoring one needs the admin role; the page says so if you do not have it.

A workspace that has never deleted anything says Nothing deleted.

Plans and pricing

The cards describe what each tier buys. None of them is a button that moves you onto one. There used to be a "Switch to Team" on every card, which meant the customer decided their own invoice — and, because Team turns on encryption at rest, decided a security posture with the same click, in either direction.

The one action on the page is redeeming a plan code. An account manager either sets the plan directly or mints a code naming your workspace and one tier; redeeming it is the owner choosing the moment, not the plan. Applying it is real work — every content row is converted to or from encrypted storage before the call answers.

Each plan is priced against the shape your workspace has right now rather than in the abstract, so the figure beside a tier is what it would cost you.

The questions it answers

A FAQ under the cards, because these are the questions that otherwise arrive as email:

• What counts as a member?
• How does the per-project charge work, and why per project as well as per member?
• What happens when I hit a limit?
• Is AI analysis included in the price?
• What does the knowledge base do?
• What does "encrypted at rest" cover?
• What happens to my data if I downgrade?
• Is the figure on this page my bill for this month?
• Can I switch billing cycles?
• How do I change plan?
• Is checkout live?

Pages with no sign-in

Each of these is opened by a token in the URL, and the token is the whole credential.

A recording link — /report/<token>

The form somebody outside your team files a report on. No account, and the token in the URL only ever files into the one project it names. A revoked or expired link says this link isn't active.

Console, network and environment are collected alongside whatever is typed. On success it says thanks — we got it.

A shared session — /s/<token>

Read-only, no sign-in: the title, description, page, console, network (each with its count) and environment. The API decides whether the session is shareable and strips everything internal before it arrives; where it is not, the page says you can't view this session rather than showing an empty shell. Whether a link works is Share on the report and Access on the project.

Your reports — /track

The reporter's own view of what they have filed, deliberately outside the dashboard shell: the people who land here have no account and no workspace, and a sidebar full of projects they cannot open would be noise at best.

Signing in is an address and then a code emailed to it — there is no password because there is no account. The address is the identity, and proving they can read mail at it is the whole of the claim.

Each report opens on three sections: what you sent, updates from the team, and what was captured — operating system, browser, device, timezone, console messages, network requests. A reporter who has filed nothing sees nothing here yet, with a line saying reports they file will show up here with their status. Sign out is in the corner.

Get the app — /get

On a phone, the download button — the only thing anybody arrives here wanting. On a desktop, a QR code, because the app cannot be installed on the machine you are reading this on and the remaining problem is getting a URL across to a device three feet away, which a camera solves and a typed address does not. Opened inside the app itself it says you're already in the app.

Public on purpose: somebody scanning that code is not signed in on their phone yet, and an install page behind a login asks you to type a password on the device you are trying to set up.

An invitation — /invite/<token>

See Getting in.

The platform console

BugCatch staff only. The API gates it on the super-admin flag, and it is routed only when that flag is reported.

Platform staff act outside membership, so none of it is reachable by a workspace's own admins — and every action is written to that workspace's audit log, which is the only trace the customer sees afterwards.

Workspaces

Every tenant, searchable. Opening one gives Manage organization, a dialog with a tab per job — one job on screen at a time, and the destructive one behind a tab you have to choose, rather than "delete permanently" sitting a flick of the wheel from a checkbox.

Every action is written to that workspace's own audit log, which is the only trace the customer sees afterwards.

Announcements

What the dashboard says to customers: a composer beside a live preview built from the real components rather than a drawing of them, because somebody choosing a tone and a colour is designing something they would otherwise not see until it was on every customer's screen.

Tones carry guidance rather than being picked by hue — Info is the default and right for almost everything; Success is for something the customer asked for arriving. The colour can follow the tone or be a colour of your own, as hex.

Each announcement in the list says whether it is live for its audience, and bump the revision shows it again to people who had closed it. What a customer sees is a dismissible product announcement bar at the top of their dashboard.

Reviews

Composing a review, sending it, chasing it and reading who has not answered. Not the tenant's to do: a mandatory review opens in front of somebody's dashboard until they answer, and the admins and owner it would do that to are the same people who would otherwise be writing it.

New review takes a title and description, then what it asks for — a rating, with its scale, and/or written feedback, with the label for the box. Then the timing:

The table underneath is who has answered and who has not.

When something looks wrong