Backing Services

The health of the platform’s backing services: its health checks, its Celery task queues and its database.

The Smarter Operations MCP server’s platform_status tool (PlatformStatusTool) uses this module to tell whether a problem that a user reports, e.g. slowness, or a prompt that never finishes, comes from the services that the platform depends on. It reads:

  • the health checks of the web console dashboard’s Service Health widget: whether the database answers a query, the cache keeps a value, the Celery broker accepts a connection, and a Celery worker answers a ping. health_checks() runs the dashboard’s own checks, run_health_checks(), rather than a copy of them, and runs them now, rather than reading the dashboard’s one-minute cache.

  • the depth of each Celery task queue: how many tasks wait for a worker. A queue that grows means that the workers are behind, or down, and that background work, e.g. a deploy, is late.

  • the database’s load: its open connections, its running queries, and its slow queries. A database that is near its connection limit refuses new requests.

Nothing is cached, and nothing is written. Each function reads the service once when it is called.

Note

Experimental. The MCPServer was designed and coded by Claude Code (Anthropic’s Claude Opus 5.5), with Lawrence McDaniel as co-author. It is experimental, and will be documented.

class smarter.apps.mcpserver.status.platform.DatabaseLoad(connections=None, max_connections=None, running=None, slow_queries=None, aborted_connects=None, uptime_seconds=None)[source]

Bases: object

The load of the platform’s MariaDB database, as platform_status reports it.

database_load() builds it from MariaDB’s status counters. Each field is None if MariaDB did not report it.

__init__(connections=None, max_connections=None, running=None, slow_queries=None, aborted_connects=None, uptime_seconds=None)
aborted_connects: int | None = None

The connections that failed since the server started, e.g. with a bad password (Aborted_connects).

connections: int | None = None

The open connections, from every pod of every component (Threads_connected).

max_connections: int | None = None

The most connections that MariaDB accepts (max_connections).

Beyond it, new connections are refused.

running: int | None = None

The queries running now (Threads_running).

Many, for long, means that queries wait on each other.

slow_queries: int | None = None

The queries slower than long_query_time since the server started (Slow_queries).

uptime_seconds: int | None = None

The seconds since the server started (Uptime).

A small number means that it restarted recently.

smarter.apps.mcpserver.status.platform.database_load()[source]

Read the database’s connections, running queries and slow queries.

Side effects: two read-only queries on the platform’s database connection, SHOW GLOBAL STATUS for the counters of DATABASE_STATUS, and SHOW VARIABLES LIKE 'max_connections'. Nothing is written.

Return type:

DatabaseLoad

Returns:

The database’s load.

Raises:

django.db.Error – If the database cannot be queried, e.g. because it is down. The caller reports that, rather than a load of zero.

smarter.apps.mcpserver.status.platform.health_checks()[source]

Run the web console dashboard’s health checks, now.

These are the checks of the dashboard’s Service Health widget, HEALTH_CHECKS: Database, Cache, Task Broker and Workers. They run now, uncached, because a help desk question is about this moment. A check that raises counts as failed: it never raises.

Side effects: a SELECT 1 on the database, a value written to the cache and deleted, a connection to the Celery broker, and a ping of the Celery workers, which waits up to half a second for their answers.

Return type:

list[tuple[str, bool]]

Returns:

The name of each check, and whether it passed, e.g. [("Database", True), ...].

smarter.apps.mcpserver.status.platform.queue_depths()[source]

Count the tasks that wait in each Celery queue, for a worker to run them.

Each queue is declared passively on the broker: the broker reports how many messages the queue holds, and does not create a queue that does not exist. A queue that cannot be read is reported as None, rather than as empty, so that “unknown” is never mistaken for “no backlog”. It never raises: a broker that cannot be reached makes every queue None, and is logged.

Side effects: one connection to the Celery broker (Redis), which is closed before it returns. Nothing is written to a queue.

Return type:

dict[str, int | None]

Returns:

The number of waiting tasks of each queue of task_queues(), by the queue’s name, or None for a queue that could not be read.

smarter.apps.mcpserver.status.platform.task_queues()[source]

Name the platform’s Celery task queues.

Return type:

tuple[str, ...]

Returns:

The default queue, which runs most background work, e.g. prompts’ follow-ups, and the infrastructure queue, which runs deploys, DNS and certificate work, from smarter_settings.llmclient_tasks_celery_task_queue and smarter_settings.infrastructure_tasks_celery_task_queue.