Version: Next — legacy draft snapshot

Access logs

Retained Next source

This page preserves the merged Next documentation snapshot at e1ddcf6940adb7b619ce509063749e740eecc795. It can describe implementation beyond the source revision selected for the rebuilt Next guides. Retain the implementation-scope notes below and confirm your deployed version before applying these details. This is not a current-release availability or deployment claim. For the task-based entry point, see the rebuilt guide.

Path: /admin-settings/access-logs

Read-only audit feed for privileged-access events: successful and failed logins, logouts, password changes, session ends, and platform-wide role grants/changes/revocations. Use it when investigating account lockouts, password resets, unexpected SUPERUSER activity, or support tickets that mention login problems.

TelWeb mutations that change platform configuration or membership also emit actor-context audit records so Super Admins can correlate UI actions with the same feed.

Event types

Events come from three categories — AUTH, ROLE_MANAGEMENT, and USER:

Action filter	Category	Meaning
Login (success)	AUTH	User signed in successfully.
Login (failed)	AUTH	Failed attempt (lockout, bad password, and so on).
Logout	AUTH	User signed out.
Password change	AUTH	Password was changed or reset.
Session end	AUTH	Session ended (timeout, idle logout, admin action).
Role granted	ROLE_MANAGEMENT	User received a team or platform role.
Role changed	ROLE_MANAGEMENT	Existing role membership was updated.
Role revoked	ROLE_MANAGEMENT	Role membership was removed.
User created	USER	A platform user account was created.
User updated	USER	A platform user account was updated.
User deleted	USER	A platform user account was deleted.

The Details column may include a reason chip — for example lockout cause or role-change context.

Filters

Control	Description
Action	Narrow to one event type, or All actions.
Search	Match user name, email, client IP, or MSISDN (partial match).
From / To	UTC datetime window for the incident you are reviewing.
SuperAdmins only	Limit results to events involving SUPERUSER accounts.
Refresh	Re-query the latest 100 matching rows (does not paginate beyond that cap).

Password-reset events keep the requester and affected account distinct. A self-service request can be anonymous; a completed reset identifies a token holder. The Details column shows the affected email as Target, while User remains the requester identity. The stored event also retains the affected account ID. This avoids attributing an unauthenticated request to the account owner.

Role grant / change / revoke events put the impacted user — the person whose role changed — in the User column (<name>, falling back to email), with the user ID shown as a caption beneath. The acting administrator is shown separately in Details as Changed by (<name> (<email>)). Team-role grants and revocations emit the same target* identity as platform-role changes, so a role transition always names both who was affected and who acted. User create / update / delete events follow the same pattern: the affected account appears in User, the acting administrator in Changed by. Rows written before the target identity was recorded still resolve the impacted user's name and email from the stored user ID at read time.

List columns

Column	Description
Date / Time	Event timestamp (UTC).
Type	Action chip (login, role granted, and so on).
User	The impacted user for role- and user-management events; the acting administrator for auth events (username or email when available).
IP	Client IP recorded for the event.
MSISDN	Phone identifier when the event carried one.
User Agent	Browser or client user-agent string (truncated with tooltip).
Details	Optional reason or supplemental context.

Typical workflows

Investigate a lockout

Open Access logs and filter Login (failed).
Search for the user's email.
Set From / To around the support ticket time.
Read Details for lockout reason, then cross-check Team users if an admin reset is needed.

Review a role change

Set the UTC time window around the change and select All actions first. Platform-role transitions have dedicated events, distinct from team-role grants and revocations.
Inspect the User column for the impacted user and Changed by in the details for the acting administrator, plus previous/new roles and outcome. Search by the actor's email if a target-email search does not find the event.
Confirm a PLATFORM_ROLE_CHANGE_SUCCEEDED event. A started challenge alone does not prove the role changed.
Correlate with the Platform role in Users and teams, target re-login, and the separate notification delivery.

Stored action	Meaning
`PLATFORM_ROLE_CHANGE_STARTED`	Challenge started or code resent; no completed change yet.
`PLATFORM_ROLE_CHANGE_SUCCEEDED`	Role transition committed with session invalidation and a queued target notification.
`PLATFORM_ROLE_CHANGE_DENIED`	Transition or verification denied; inspect the reason.
`PLATFORM_ROLE_SESSION_CLEANUP_FAILED`	Session-tracking cleanup failed; investigate operations logs. The database session version still invalidates old sessions.
`SUPER_ADMIN_RECOVERY_ELEVATED`	Audited setup/recovery elevation, including operator identity and change reference.
`SUPER_ADMIN_RECOVERY_DENIED`	Setup/recovery elevation denied.

The successful platform-role audit is persisted with the role change. Email delivery happens asynchronously; verify delivery separately in Job history.

Access logs complement per-team user management: team ADMINs manage membership in Settings → Users; SUPERUSERs review the platform-wide audit trail here.

Retention

By default, Tasker cleans audit / access-log rows older than 180 days (AUDIT_LOG_RETENTION_DAYS). Operators can adjust the retention window and cron schedule on the Ops host — see Ops service.

Export

For SIEM ingestion of security events, see Security event export.

Event types​

Filters​

List columns​

Typical workflows​

Investigate a lockout​

Review a role change​

Retention​

Export​

See also​