Access logs
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 two categories — AUTH and ROLE_MANAGEMENT:
| 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. |
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.
List columns
| Column | Description |
|---|---|
| Date / Time | Event timestamp (UTC). |
| Type | Action chip (login, role granted, and so on). |
| User | 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
- Filter to Role granted, Role changed, or Role revoked.
- Optionally enable SuperAdmins only when auditing privileged accounts.
- Correlate with changes on Users and teams.
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.
See also
- Users and teams — where role changes are made.
- Team users — per-team lockout, password expiry, and session limits.
- Roles and access — role model and SUPERUSER password policy.