Audit Log

Introduction

What is the Audit Log?

The Audit Log records the consequential actions that happen across Testver — sign-ins, configuration changes, data mutations, file edits, defect status changes, and more. It is the system’s memory of who did what, and when, and it is how you answer questions such as:

• “Who deleted that test plan?”
• “When was the JIRA token last rotated?”
• “Did anyone change the configuration in the last 24 hours?” Each entry is a compact, structured fact: an action type, the user who performed it, the resource it touched, a timestamp, and — for some entries — an expandable block of details.

Caution

The Audit Log is visible only to users with the Admin role. The personal subset of this view (your own actions) is available to everyone under Profile ▸ Recent Activity.

Note

In one sentence: the Audit Log is the admin-only, filterable, exportable record of every consequential action in Testver.

Who this guide is for

• Admins performing routine security hygiene or investigating an incident.
• Compliance and security stakeholders who need an exportable trail of changes.
• Team leads answering “what changed and who changed it?” after an unexpected result.

Key terms

Term	What it means
Event	A single recorded action — one row in the log.
Action	The type of event, written as a dotted key such as auth.login, test.create, or defect.update.
User	Who performed the action. Automated actions are attributed to “system”.
Resource	What the action affected — a test case, a plan, a connector, a setting, and so on.
Details	An optional JSON payload attached to an entry, shown when you expand the row.
Redacted	Sensitive values (such as API keys) are recorded as placeholders, never in clear text.

The guiding principle: actions, not content

The Audit Log records actions, not content. The design rule is simple: capture enough information to investigate, but never enough to leak personal data. You will always be able to see that something happened and who did it — but the log deliberately does not store what users typed, recorded, or generated.

Getting Started

Opening the Audit Log

1. Sign in as a user with the Admin role.
2. Open the Admin section in the navigation and choose Audit Log.
3. The audit stream loads, newest events first.

Tip

If the Audit Log entry isn’t in your navigation, your account is not an Admin. Non-admins should use Profile ▸ Recent Activity for their own history.

The screen layout

Audit Log is a single-screen stream made of four parts, top to bottom:

1. Header stats — quick summary cards.
2. Filters — narrow the stream by action type and user.
3. Log table — the events themselves, paginated.
4. Per-row expansion — additional details for entries that have them.

Header stats

Four stat cards run across the top of the screen, giving an instant security snapshot:

Card	What it shows	Why it matters
Total events	Count across the whole audit history.	A sense of overall activity volume.
Unique users	Distinct users who appear in the log.	How many people have actually done something.
Logins (24h)	Successful sign-ins in the last day.	Normal daily access baseline.
Failed logins (24h)	Failed sign-in attempts in the last day.	Flagged amber/red when non-zero — a first signal of brute-force or probing activity.

Tip

Failed logins (24h) > 0 is the single fastest thing to check after a suspected security event. Even a small number can indicate someone probing for access.

Filters

Two filters sit above the table and combine with each other:

• Action filter — select an action type (e.g. auth.login, test.create, defect.update) to scope the log to a single category.
• User filter — pick a specific user to see only what they did. Filters combine, so you can ask precise questions like “every settings change made by this user”. Clearing the filters returns the full log. Changing a filter resets pagination back to page 1.

Tip

During incident response, filter by the user of interest first — it narrows the stream to one person’s actions and gives you the fastest narrative reconstruction.

What’s logged

The Audit Log records action categories spanning the whole product. Recorded categories include:

Category	Examples of recorded actions
Auth	Login, logout, password changed, session revoked.
User management	User created, role changed, account disabled / enabled / deleted.
Test management	Test case created / updated / deleted; plan and cycle operations; defect changes.
Run	Runs started, completed, and cancelled.
AI	AI Assistant tool calls, generations, and recordings made — the fact of the call only.
File / Git	File writes and deletes; commits.
Connector	Connector created / edited / deleted; test-connection performed.
Settings	Settings changes — sensitive values such as API keys are recorded as redacted.

What is NOT logged

Some things are personal data and are deliberately kept out of the audit trail. They remain strictly user-scoped:

• Chat content — what users typed in the AI Assistant or Skills Chat.
• Recording content — what was captured in AI Record.
• Generated case content — the bodies of cases produced by AI Test Gen.

Caution

The Audit Log answers “what happened?”, never “what was said?”. For AI features it records that a call occurred — not the conversation itself.

The log table

Each row in the stream shows:

• Action — the action type, e.g. auth.login or defect.update.
• User — who performed it; “system” for automated actions.
• Resource — what was affected.
• Timestamp — when it happened.
• Details indicator — a chevron appears when the entry has expandable details.

Per-row expansion

Click the chevron on a row to expand it. The entry’s details payload is shown inline as pretty-printed JSON — ideal for “what fields changed in this update?” investigations. For example, an update event might show the before/after of the changed fields:

{
  "action": "defect.update",
  "user": "asha",
  "resource": "DEF-128",
  "details": {
    "status": { "from": "open", "to": "resolved" }
  }
}

Pagination

Entries are paginated. Use the page controls at the bottom of the table to move through history. Remember that changing a filter resets you to page 1.

Export

The Export button at the top downloads the full audit log as JSON. It is useful for:

• Offline review outside the app.
• Attaching to compliance or audit reports.
• Shipping into an external SIEM or log-analysis pipeline.

Tip

Export on a regular cadence (e.g. monthly) so you retain a durable record even as the in-app history grows.

Common workflows

The weekly five-minute review

1. Open the Audit Log.
2. Filter to settings changes and review them.
3. Filter to user-management events and confirm each was expected.
4. Glance at Failed logins (24h) in the header stats.

Investigating “who deleted X?”

1. Filter the Action to the relevant delete action (e.g. a test or plan deletion).
2. Scan the rows for the resource in question.
3. Expand the row to read the details and confirm the user and timestamp.

Reconstructing one user’s activity

1. Set the User filter to the person of interest.
2. Page through their actions in chronological context.
3. Expand rows where details matter to see exactly what changed.

Tips & best practices

• Audit Log every Friday for five minutes. Filter to settings changes and user-management events and you’ll catch most issues early.
• Failed logins (24h) > 0 is the first thing to check after a suspected security event — even a small number can indicate exploration activity.
• Filter by user during incident response — it gives the fastest, cleanest reconstruction of one person’s actions.
• Export periodically so you keep a durable, off-platform record for compliance.

Troubleshooting

Symptom	Likely cause & fix
I can’t see the Audit Log	Your account is not an Admin. Use Profile ▸ Recent Activity for your own history, or ask an admin.
A row has no expand chevron	That entry simply has no extra details payload — the summary line is the whole record.
I can’t find the AI chat someone typed	By design. Chat, recording, and generated-case content are never logged — only the fact of the call.
Filters return nothing	The action/user combination has no matching events. Clear one filter to widen the search.
An API key looks blank in the details	Sensitive values are redacted on purpose; the log never stores secrets in clear text.
Failed logins are climbing	Investigate immediately — filter to auth actions and the affected user, and consider revoking sessions and rotating credentials from the Users screen.

Frequently asked questions

Can a Tester or Viewer see the Audit Log?

No. It is admin-only. Non-admins can see their own actions under Profile ▸ Recent Activity.

Does the log store passwords or API keys?

No. Auth events record that a password changed, not the password itself; settings events redact sensitive values such as API keys.

How far back does the log go?

It retains the full recorded history available to your instance. Export periodically if you need a durable archive beyond the in-app view.

Are automated actions logged too?

Yes — actions performed by the system (e.g. scheduled runs) are attributed to the “system” user.

Related screens

• Users — the accounts whose actions you are auditing, and where you respond to findings.
• Profile ▸ Recent Activity — the per-user, personal subset of this view.
• Settings — configuration changes that show up in this log.

Related screens

• Users — the accounts whose actions you are auditing, and where you respond to findings.
• Profile ▸ Recent Activity — the per-user, personal subset of this view.
• Settings — configuration changes that show up in this log.

Related

• Users — user actions to audit.
• Profile → Recent Activity — personal subset of this view.
• Settings — settings changes appear in this log.