Use Settings, the administration area in the web chat, to inspect a running installation. Metnos can also produce an HTML report that opens as a local file. It is a technical snapshot of the moment when it was generated, not a second version of Settings.

1. Where to start

You can ask Metnos directly:

Show me where I can check the latest turns and service status.

The simplest route starts in the web chat: Settings > Activity > Turns for recent requests and Settings > System > Services for configured services. If you are talking to Metnos through Telegram, you must still open these pages in a browser because Telegram does not contain the administration area.

APIs, logs, and files are useful for technical diagnosis. The static report described below belongs to this second case and is not the ordinary route for chat users.

2. The two tools

These are not two views of the same facility. Settings uses its own pages and data, while the static generator runs only from the command line and is not used by the HTTP server.

3. Settings in the chat

The Settings landing page summarises version and uptime, turns over the last 24 hours, proposals, executors, scheduler activity, Safety signatures, and users. Detail pages keep different operational questions separate:

runtime/ui_surfaces.py is the canonical description of visible pages and their navigation routes. Tutor uses the same registry, so a structural interface change also requires an updated navigation guide and a rebuilt Tutor index.

Monitor: requests and model performance

Sidebar sections collapse; the current page's section opens automatically. Monitor > Overview plots complete request throughput and duration; Requests opens an individual query and its calls; Model performance compares logical and physical identities, with six charts in this order: full call throughput, mean call duration, prefill (PP), generation (TG), input tokens and output tokens. Mean duration in seconds is the arithmetic mean of observed full call durations per model and time bucket; missing timings are excluded, observed zeros are retained, and intervals without measurements remain empty. Filters cover period, channel and origin, with JSON export of the selected view. Origin defaults to All: interactive, background and test activity are included, along with unattributed calls in model statistics. Selecting an origin restricts the view to that origin.

LLM call throughput divides output tokens by full call duration, including prefill, generation, queueing and transport. The average is duration-weighted: total tokens divided by total duration of valid calls. Request end-to-end throughput divides output tokens by request duration. Active time excludes waiting for the person; total time includes it. Prefill and generation use only timings reported by the provider. Missing tokens or timings remain unknown. Aggregate rates use sums of valid token counts and durations.

The expandable How measurements are calculated panel also defines the terms used: model measurement coverage, observed/expected calls in requests, valid/total samples, mean, median and 95th percentile, along with tokens, PP/TG phases and data quality. Ratios such as 8/10 have examples; token and timing completeness is distinguished from observed call counts. The model table also shows Average prompt in tokens: known input tokens divided by calls with known input counts, within the filtered period and selected logical/physical grouping. It includes the full prompt, with any instructions, history and tools; cached tokens are included when part of the provider's input count. Calls without counts are excluded from the mean; the ratio of known counts to observed calls appears below the value. The median duration header wraps to keep the table compact; numeric values remain aligned.

Charts refresh every five seconds while the page is visible. Charts show separate points; distinct colors identify the same series across charts. Legends use matching filled dots, without solid or dashed line samples. Dates show day/month and UTC time; the complete timestamp is available on hover. A buffer of 128 events per process hands measurements to a writer thread without waiting for disk. Lost events, incomplete data and stale collection are shown on the page. Collection retains identifiers and measurements, without questions, answers or credentials. Access requires the admin role.

Each Monitor screen remembers applied filters, the time period, model grouping and selected series in the browser. Preferences are separated by authenticated user and screen, and survive restarts when using the same browser. Relative periods, such as the last 24 hours, are recalculated on opening; a custom range retains its dates. A link with explicit parameters takes precedence over saved preferences. Settings are saved after a successful load, without writes during regular automatic refreshes. If the browser prevents saving, the page reports this and remains usable.

Database aggregation and 90-day history

The collector writes analytical records directly to SQLite in a thread separate from the LLM call. Statistical SELECTs apply the period and filters before grouping by interval, provider, logical name and physical model. Summaries have no 10,000-sample limit: the page receives aggregates and at most 200 detail rows per page. Charts have at most 500 intervals and 12 selected series; hiding a series or changing pages does not change summaries for the filtered period.

Each token chart point shows the mean known count per call, while cards and tables also retain totals. Call duration uses the mean; request duration uses the median and nearest-rank 95th percentile over all valid samples. Speeds use summed tokens divided by summed valid durations. SQLite sorts percentiles using disk-backed temporary storage and a 4 MiB cache per connection, without loading historical records into Python lists.

The rolling window retains 90 days of analytical data. At most once an hour, on the next write or read, a transaction deletes closed requests, segments, calls and revisions with no activity in the last 90 days. Freed pages are reused without a full compaction on every deletion. Open requests and chains with recent activity remain until the whole chain expires. Importing an old event does not restore expired records. Old JSONL files are imported in bounded batches, with a warning while unread bytes remain; the new collector does not append to them. Cumulative health counters remain separate from analytical records.

4. The static HTML snapshot

The generator reads local sources and composes one document with embedded styles, no JavaScript, and no live connection to the server. Sections are ordered as follows: tests, Mnestoma, pairings, recent turns, Vaglio decisions, and scheduler.

Each collector handles an unavailable source separately. The page can therefore be produced when one section is empty or reports an error. This makes a partial snapshot readable; it does not make missing data evidence that the corresponding component is healthy.

The generated document currently uses Italian labels and lang="it". It is not a localised chat surface and must not be presented as one.

5. Data collected by the snapshot

Limits are fixed in the generator and cannot be changed from the command line: at most five turn files, three Vaglio files, and a bounded number of rows or events per section. The report helps direct a diagnosis; it is not a source for complete totals.

6. Access, users, and confidentiality

• Settings is an installation-wide administration view. Middleware admits only the admin role; summaries may cover several users. It is not an individual user's personal view.
• The static snapshot is installation-wide too. It may contain requests, answer excerpts, sender identifiers, and pairing metadata belonging to different users.
• HTML escaping is not access control. The generator escapes dynamic text before inserting it into the document, but anyone who can open the file can still read its content.
• Upstream redaction is not an absolute guarantee. Records may remove recognised credentials, but the snapshot must still be treated as confidential data.
• The file sets no permissions of its own. It inherits its directory, owner, and process umask; it must not be placed in a publicly served directory.
• A snapshot remains on disk. Regenerating overwrites the chosen path, but does not remove moved copies, backups, or files created with another --out.

7. Generation and lifetime

From the installation root, using the Metnos Python environment:

PYTHONPATH=runtime ./.venv/bin/python -m observability render
PYTHONPATH=runtime ./.venv/bin/python -m observability render --out /chosen/path/dashboard.html

The default destination is PATH_WORKSPACE/dashboard/index.html. The command reports the written path and exits. There is no built-in periodic refresh: generation time and content remain unchanged until the command runs again.

The file is derived output. It can be removed by deleting only the selected output path after confirming that no process uses it; removing it does not delete any operational source.

8. Verification and canonical sources

Focused tests for the static generator live in tests/runtime/runtime/test_observability.py. They verify, among other things, that executor names, requests, and responses cannot introduce active markup into the file. HTTP and end-to-end tests cover administration pages separately; this guide does not freeze a test count that would become stale.

• runtime/http_routes_admin.py — Settings data and actions;
• runtime/http_auth.py — authentication boundary for /admin routes;
• runtime/ui_surfaces.py — editorial registry of visible surfaces;
• runtime/observability.py — static snapshot generator;
• runtime/config.py — canonical installation paths.