Activity log

Traceability → Activity. A record of who changed what, and when. It is the answer to "who moved this test case to Archived", "who took Priya out of the organization", and "was that me or was that my AI assistant".

:::note Recently changed The activity log is new. It records from the day it was switched on — there is no history from before that, and nothing is backfilled. :::

What is recorded

Every create, update and delete of a test case, bug hunt, session, requirement, folder, shared step or Milestone, whoever made it and however they made it: the web app, an AI connector, an API token or the CLI.

Every property counts. Moving a test case's automation status from Can be done to Done, changing its state or estimate, retagging it, moving it to another folder, flagging it unstable, approving it, adding or removing people from a session — each is recorded with what it was before and what it is now.

Comments and bugs count too. A comment on a test case, a session, a bug hunt or an automation run, and a bug reported in a hunt or a session, are all recorded — against the thing they are about, so they appear on that test case's or that session's own history rather than somewhere of their own.

A bug's status moving is recorded as well, and the row says the move itself: Moved a bug from Open to Done on session Checkout: Login fails. That sentence is on every plan that keeps a log, since for a bug the move is the event; the rest of an edit to a bug — its title, severity or won't-fix reason — is in the field-level before and after, on Business.

Turning a session's comment into a bug, or a bug into a comment, is one row on the session — Converted a comment to a bug on session Checkout: Login fails — linked to the new bug or comment, rather than a bug reported and a comment deleted. See Sessions.

Clicking a row about a bug opens the bug where it was found — the session or the hunt's test case — scrolled to it and lit up, the same place the Bugs page opens it. A deleted bug's row opens the session or hunt it was in.

:::note Recently changed A bug row used to read Updated a bug on session … whatever happened to it, and opened the session or hunt without pointing at the bug. Rows recorded before the change keep their old sentence and link — the log is never rewritten. :::

A Milestone closing, reopening, or gaining or losing a hunt, session or run, is recorded too — Closed milestone, Reopened milestone, Added to milestone, Removed from milestone — against the Milestone, not against the item that moved.

:::note Recently changed Milestones are new, and are recorded here the same as any other content. :::

More of the work in a bug hunt is recorded. A hunt run step by step used to leave nothing behind but its comments and bugs. Now these are recorded too, against the bug hunt:

• a case's verdict, assignee, and being archived or hidden — Updated a case in a bug hunt
• a step's result — Recorded a step result; when it moved the case's verdict, the same row says so
• a step's text, expected result or evidence edited with no result — Edited a hunt step

:::note Recently changed None of the above was recorded before. Rows are written from the day this shipped, and nothing is backfilled. :::

Dashboards and their widgets are recorded when they are created or changed (Created a dashboard, Changed a dashboard, Added a widget, Changed a widget), with one exception: a private dashboard records nothing while it stays private, because everyone in the organization can read this log and a private dashboard is meant to be seen by its owner alone. Sharing one with the organization is recorded (shared with the organization), and so is making one private (Made a board private), with no detail of what it holds.

Three more acts are recorded: a person choosing an error's defect type (Set an error's defect type; Sekee's own automatic classification is not anybody's act and is not recorded), linking or unlinking an automated test to a test case, and creating a project.

:::note Recently changed Dashboards and widgets, an error's defect type, an automated test's links and new projects were not in the log at all before, whoever changed them. They are recorded from the day this shipped, for people and for AI assistants alike. :::

A decision on Visual Testing is recorded too — Approved visual changes and Rejected a visual change — against the automation run, and the entry links to that run's Visual Testing page. Approving is the one act that changes what every later run is compared against, so it is the row to look for when a visual regression got through. An Approve all is one entry, however many snapshots it approved.

:::note Recently changed Visual testing is new, on Business, and its decisions are recorded from the day it shipped. :::

An update that changes nothing is not recorded. The editor sends the whole form back on every save, so a page opened and closed leaves no trace.

On Business, the log also records what happens to the account itself: failed sign-ins, password changes, an owner confirming their email address (Confirmed their email address), members invited and removed, role changes, API and AI connector tokens, integrations, seats and plan changes.

:::note Recently changed Confirmed their email address is a new security event. New organizations now have to confirm the owner's email. Before this there was nothing to confirm, so there was no event for it. :::

Edits made together are shown together

Nobody changes one thing. A person fixing a test case changes its automation status, rewrites a step and retags it — three saves in ten minutes, which as three rows buries the interesting one.

So edits to the same thing by the same person within an hour are shown as a single entry — "Made 4 changes to test case Complete a card payment" — which opens to list each save in order with its own time. The window slides: two edits eight minutes apart group whether or not a clock hour falls between them.

Creating something and deleting it are always their own entries. They are not edits, and folding them into a run would tell two stories in one line.

The rows themselves are still stored separately and are never merged or rewritten — grouping is how the log is read. An export gives you one line per event.

What is not recorded

• CI results. A CI run is execution history and has its own page — see the Automation history on a test case. (A person's verdict and step results in a bug hunt are recorded now, as above.)
• Watching, and reading your notifications. Following something and marking notifications read are personal, not shared work.
• The text you wrote. A description, scenario or comment records that it changed and never what it now says. The content is in the entity; the log says when it moved.
• Step-by-step detail. Editing a test's steps records "Steps: 2 added, 1 changed" and no more. A before-and-after of every step is the longest and least readable thing a test case has, and the steps are one click away.
• Signing in. Everybody signs in every day, so it is the one event guaranteed to outnumber the work. A failed sign-in is kept: it is rare, and it is what somebody looks for when they ask whether an account was attacked.
• Reads. Opening a page is not an event.

It follows the project you are in

Switching projects narrows the log to that project's work. Anything that belongs to no single project — a shared step, a member's role, the plan — is shown whichever project is open, because it is organization work rather than nobody's.

Where it appears

Where	Shows
Traceability → Activity	The whole organization. Every member can open it.
A test case, bug hunt or session → Change history	Everything recorded about that one thing.
A requirement's row → the clock icon	The same, for a requirement.
A Milestone → its own Activity page	The same, for that Milestone.
Your profile → Activity	Your own.
Anyone's profile	Theirs — hover any avatar and choose Open profile.

:::note Recently changed Traceability → Activity used to be owners and admins only. Every member can open it now, narrowed to content events — test cases, bug hunts, sessions, requirements, folders and shared steps, plus the comments and bugs recorded against them. An owner or admin sees the organization's account events there too (sign-ins, role changes, plan changes, …); everyone else does not, on that page or anywhere else. IP address and browser are likewise shown only to an owner or admin, whatever the plan — a member reading the log sees the same content diffs with those two fields left out, rather than learning a colleague's IP address one edit at a time. :::

A colleague's profile shows changes they made to test cases, bug hunts, sessions and requirements — content events, exactly as the organization-wide page now shows anyone who is not an owner or admin. Account events — sign-ins, role changes — still appear only to owners and admins, wherever they are shown. Exporting the log to CSV or JSON stays owner/admin only regardless of who can read the page on screen.

AI assistants are marked

When somebody's AI connector makes a change, the row is attributed to the person — the assistant acts as them — and carries an AI generated badge saying so, with the connector's name in its tooltip.

This is on every plan that records at all. A row that named a person for forty edits their assistant made would be telling you something untrue, and that is not a thing to charge for.

Rows from an API token or from CI are marked the same way.

What a connector does is recorded the way a person's action is, for the actions this page lists, and each row carries the badge. The same AI generated badge marks the comments an assistant wrote, in the app and in emails; see AI connector.

:::note Recently changed The badge used to read AI. It reads AI generated now. :::

What each plan includes

	Starter	Standard	Business
Content changes		●	●
Who, when, and through what		●	●
Field-level before and after			●
Failed sign-ins and account changes			●
IP address			●
Filter by person or project			●
Export to CSV or JSON			●
Kept for	—	30 days	1 year

Starter records nothing at all. Moving from Starter to Standard starts the log from that moment.

Rows keep the retention they were written with, so moving to a smaller plan never shortens history that already exists — it stops new rows being written and the existing ones age out on their own schedule.