Platform Status
Platform Status gathers the health of your platform onto one page: what the billing queue is doing, how your users are signing in, how much of your activity comes through the API and AI assistants, and how the server itself is coping.
It is the page to open when something feels slow, when a billing run seems not to have started, or when you want a periodic check that your users’ security is in order.
Finding the Page
Section titled “Finding the Page”Platform Status is a tab on the main menu, to the right of Advanced. It needs elevated access with two-factor verification. If the tab is not there, ask your platform administrator to check your access level.
The page loads its figures when you first open the tab, and holds them. Clicking away and back does not fetch new ones, so the numbers are a snapshot from when you opened it, and Platform Time tells you when that was. Reload the page for current figures. This matters most for the queue counts, which move constantly.
Some panels need access beyond the tab itself, so you may not see all of them:
| Panel | Who sees it |
|---|---|
| Platform & Queue | anyone who can open the tab |
| User Access & Security, API & MCP Activity | users with data-protection report access for account status |
| Server Information, OPcache and APCu | platforms running on their own dedicated server |
Platform & Queue
Section titled “Platform & Queue”The billing task queue and the platform’s own mode and clock.
| Row | What it tells you |
|---|---|
| Platform Mode | Whether this is your live platform or a test one |
| Platform Time | The server clock, and effectively when these figures were taken |
| Ready Tasks | Tasks waiting to run now |
| Delayed Tasks | Tasks deliberately scheduled for later |
| Running Tasks | Tasks in progress |
| Completed with Errors (24h) | Tasks that finished but reported problems |
| Failed Tasks (24h) | Tasks that did not complete |
| Oldest Ready Task | How long the longest-waiting task has been queued |
Oldest Ready Task is the one to watch. Ready tasks are normal - work arrives and is picked up - but a ready task that has been waiting a long time means the queue is not being worked through, and anything you have just requested is behind it. A steady rise in Ready Tasks alongside it points the same way.
Failures and errors in the last 24 hours are a prompt to look at Billing Tasks itself, where you can see which task failed and why.
User Access & Security
Section titled “User Access & Security”Counts of your users and how they have been signing in. Everything here is a count or a timestamp; no individual user is named. System users are left out throughout.
| Row | What it tells you |
|---|---|
| Active Users | Active accounts on the platform |
| Active Login Users | Of those, the ones that can sign in |
| Active Elevated Users | Of those, the ones holding elevated access |
| Users Logged In (24h) and (30d) | How many distinct users actually signed in |
| Latest Successful Login | When the most recent sign-in happened |
| Failed Login Events (24h) | Unrecognised users, wrong passwords, expired passwords, inactive accounts and failed two-factor attempts |
| Platform Views (24h) and Platform Edits (24h) | Activity through the interface, excluding API and assistant activity |
| Login Users with and without Authenticator 2FA | How far two-factor authentication has been taken up |
| 2FA Users with Fewer than 3 Backup Codes | Users at risk of locking themselves out |
Two rows are worth acting on rather than just reading:
- 2FA Users with Fewer than 3 Backup Codes tells you who is heading for a lockout. A user who runs out of backup codes and loses their authenticator needs account access assistance to get back in, so it is cheaper to have them reset their backup codes first.
- Active Elevated Users is worth a periodic glance against who actually needs elevated access.
A rise in Failed Login Events is usually someone struggling with a new password, but a large jump is worth investigating.
API & MCP Activity (24h)
Section titled “API & MCP Activity (24h)”The same view and edit counts as above, but for automated access, split so you can tell the two apart:
- API Users, API Views and API Edits for the REST API
- MCP Users, MCP Views and MCP Edits for AI assistants
Keeping these separate from the interface figures answers “how much of our activity is now automated”, and makes an unexpected assistant or integration visible.
Server Information
Section titled “Server Information”Host-level figures for platforms on their own dedicated server: server uptime, logical CPUs, load average, memory available, filesystem free, and the PHP version, memory limit, execution time and upload size limits the platform is running under. Usage bars show server memory and platform filesystem use as percentages.
Filesystem Free is the one that causes trouble if ignored: billing runs generate bills, CDR files and disaster recovery archives, and a platform that runs out of disk stops doing all three.
OPcache and APCu
Section titled “OPcache and APCu”Two caches that keep the platform quick. Each shows whether it is enabled, its hit rate and memory use, and how much it is holding.
A healthy hit rate is high. A low hit rate, or a cache reporting itself as full or heavily fragmented, is worth raising with support rather than acting on yourself.
When Something Looks Wrong
Section titled “When Something Looks Wrong”Panels degrade rather than error. A figure the platform cannot read shows as Unavailable, and a panel that cannot be built says so, leaving the rest of the page working.
If the queue is backing up, disk is filling, or the security counts look wrong, contact support with what the page shows.
Related Pages
Section titled “Related Pages”- Billing Tasks - the processing queue behind the Platform & Queue panel
- User Management - accounts, permissions and security settings
- Account Access Assistance - helping a user who cannot sign in