Logs and Monitoring
Logs answer "who did what and when"; the monitoring pages handle live sessions and files. Menu path: System Management → Logs / System Monitoring.
All three log pages support clearing history by age (choose from 3 / 7 / 30 / 60 / 90 / 180 / 365 days ago); clearing is irreversible and runs only after confirmation.
Login Logs
Records every login attempt (success and failure):
- Filters: user account, login status;
- List: account, status, login IP, OS, browser, message, time;
- Detail additionally includes: login client (admin panel / merchant panel), login method (password / verification code / passkey, etc.), login location.
To check "is someone brute-forcing this account": filter by account and see whether the failed attempts cluster on unusual IPs and locations.
Operation Logs
Records write operations by admin-panel users (create/delete/update, publish, config saves, etc.):
- Filters: operation module, operator account, operation status;
- Detail contains the full request parameters and response (pretty-printed JSON, handy for verifying "what exactly was changed"), plus HTTP method and URL, operation IP and location.
To trace "who changed this record": filter by operation module + time range and look for the field changes in the detail's request parameters.
Open API Logs
Records every call merchants make to the unipay open API — the first stop for troubleshooting integration problems:
- Filters: merchant number, request ID, API path, trace ID, status;
- List: API name, status, elapsed time, client IP, error message, merchant, call time;
- Detail: full request parameters and response message, error code, and the real client IP vs the merchant-declared IP (a mismatch usually means a proxy or forgery — a key risk-control signal).
Order for troubleshooting merchant integration problems
Filter failed records by merchant number in the Open API logs → read the error code and message (signature errors / parameter errors / insufficient permission each have distinct codes) → when message-level verification is needed, expand the request parameters and compare them with the merchant's original request. For a general integration error reference, see Business System Integration.
Online Users
The list of live signed-in sessions, with forced sign-out:
- Filter by username, account, client (admin panel / merchant panel); one account signed in on multiple clients shows multiple rows (one per session);
- "Force offline" runs on a single session or on checked sessions in bulk — it only terminates the session and does not lock the account; the user can sign in again immediately. Well suited for cleaning up sessions left signed in on shared computers.
Login Lockout
The record page for lockouts triggered by the Login Security policy:
| Status | Meaning |
|---|---|
| Counting | Failures below the threshold; only counting |
| Locked | Locked; remaining minutes shown |
| Expired | The lock period has passed; cleared automatically at the next login |
"Unlock" also clears the failure counter, so the user can retry immediately. When a user reports "cannot log in", check here for a lockout first, then the account status.
Leftover history
If a notice at the top of the list says "login lockout is disabled", the current policy has turned failure lockout off and the list is only pre-change history; the unlock action still works.
File Records
The ledger of every file in platform storage (files uploaded by each business are aggregated automatically):
- Filters: file name, original file name, access type (public / private), business category;
- Actions: preview (opens in a new window), download, detail (file size, MIME type, storage path, business category, etc.);
- This page is read-only — delete files on the business page that produced them; "business category" helps identify where a file came from.
Related Links
- System Security Configuration: the policy switches behind these logs
- User Management: account status and lockout mechanics
- Business System Integration: open API error reference