Stoa Docs

Appearance

System status ​

The System status page is the live view of your Stoa deployment's health. Host resources, every core service, and a running count of model activity are visible at a glance. This page explains what you're looking at, how to read it, and what to do when something goes yellow or red.

What the page shows ​

In the admin UI, open the user menu, choose System. The Status tab (the default one) is laid out in a few sections.

The summary bar ​

Across the top: an overall status badge (green, yellow, or red, the worst state of anything below), how long the platform has been running since it last started, a running total of model calls made since the deployment was first used, and, when there's activity right now, a live count of calls currently in flight.

Host resources ​

Three cards show the host machine itself:

  • CPU, as a percentage, with the core count and load average alongside.
  • Memory, as a percentage, with used and available amounts alongside.
  • Disk, as a percentage, for the primary storage volume, with used and total amounts. If Stoa's documents and its other storage live on more than one volume, the others are listed underneath in an Additional storage panel.

These are sampled live from the host. They're the first place to look when chats feel slow or ingestion stalls.

Cache storage ​

A separate panel reports the text Stoa has read out of attachments and fetched web pages, kept so a repeat reference doesn't have to be read again. It shows the total size and number of entries, plus a Clear cache button for admins who want to reclaim the space. Clearing it doesn't delete anything from your knowledge bases: it just means the next time something references a cleared attachment or page, Stoa reads it again, which costs a model call if the content includes images.

Services ​

Below that is a list of the platform's core services. Each row shows:

  • The service, in plain language: the database, the cache, the document converter, and the language model service.
  • A status badge: green for healthy, yellow for degraded, red for down.
  • Latency in milliseconds for the most recent health check.
  • Notes, when relevant: an error detail if something's wrong.

TIP

The page refreshes itself every 10 seconds. You don't need to reload to see the latest state, just leave the tab open during a maintenance window.

What "degraded" means ​

A service goes yellow when it's responding, but slowly, or returning intermittent errors. Yellow is a warning, not a failure: chats and queries still work, but some requests may take longer than they should. Common causes:

  • The host is under load. Look at CPU and memory above. If either is above 90%, you've found the cause.
  • Disk is nearly full. Anything over 90% disk usage will start affecting writes and document ingestion. Free space, or expand the volume.
  • Network or DNS hiccup between services. Usually resolves on its own. If it persists, your delivery engineer can dig in.
  • An unusually large request in flight (a huge document being converted, a long-context research job). The service catches up once the request finishes.

What "down" means ​

Red means the health check is failing entirely. The service isn't responding within the timeout. This is a real outage for that service:

  • Database down: sign-in, history, settings, and audit are all unavailable. The platform is effectively offline.
  • Cache down: the platform still works but is slower.
  • Document converter down: chats still work, and existing knowledge bases still answer questions, but anything that needs a document converted (uploading a new Office document, a PDF, or importing a web page) will fail until it's back.
  • Language model service down: the model itself is unavailable. Chats and research jobs will fail until it comes back.

What to do when something is degraded ​

A short triage checklist:

  1. Check the host resources at the top of the page. CPU, memory, or disk above 90% is almost always the actual cause.
  2. Check whether more than one service is affected. If several are yellow at once, it's a host-level issue, not a single-service issue.
  3. Wait 30 seconds and refresh. Brief spikes are normal during heavy use. Persistent yellow is the kind that needs attention.
  4. Check the Audit log for any recent configuration changes that line up with the time the status changed.
  5. If you can't resolve it within a few minutes, contact your delivery engineer. Persistent red is not something you should debug alone.

Health check expectations after install ​

Right after Installation, every service should be green and host resources should be in a comfortable range (well under 50% on a fresh deployment with no users). If anything is yellow or red on day one, the install isn't done yet.

Permissions ​

Viewing the System status page requires its own view-only permission, separate from the ability to change any configuration. By default, only admins have it, but you can grant a custom "operator" role read-only access to system status without giving them permission to change anything. Clearing the cache from this page is a separate, more privileged permission, so a read-only operator can watch this page without being able to act on it. See Roles & permissions.

Next ​

Stoa, a MicroApps product.

Copyright © Stoa & MicroApps