Logs and diagnostics

This page is for administrators. It covers where the gateway says what it is doing (its own log and each module's log), how to see how hard it is working (the Diagnostics page and the @gateway.performance tags), and the health endpoint a monitor can poll.

The gateway log

Open Gateway, then Logs. "The newest gateway messages. They are kept in memory, so a restart clears them." Anyone who is not an administrator sees "Only administrators can read the gateway log."

• The gateway keeps its last 2,000 lines in memory. Nothing is written to disk by this page; the same lines also go to the container's console, which is where to look for anything older.
• The page shows Time, Level, Source (the logger category) and Message, newest first, and refreshes every 5 seconds.
• A level filter chooses the minimum level: Information, Warning or Error. The search box filters by message text. Clear filters resets both.
• Module lines are not here. Each module has its own log (next section). They still reach the console under the category Module.<id>.

API

Route	Role	Purpose
GET /api/v1/admin/logs?level=&search=&before=&limit=	admin	Newest first; level is the minimum (default Information), limit 1 to 1000 (default 200), before pages

Module logs

Every module writes through the logger it is given, and the gateway keeps that log apart from its own. Open Gateway, then System, then Modules, and pick a module; Modules describes the page.

• The last 2,000 lines of each module are held in memory for the dashboard and the API.
• Each module also writes rotating files, DATA_DIR/logs/modules/<id>/module.log, up to 2 MB each with the newest five kept. They survive restarts, and the download route serves them oldest first.
• Each line has a time, level, message, optional exception, and the instance it concerns (a connection, a broker) when the module wrote it under a scope. Lines the gateway wrote about the module itself (started, stopped, failed, who asked, which tags it marked bad) are in the same log with source: "host".
• Each module has its own level, information by default: trace, debug, information, warning, error or critical. Changing it takes effect at once and is remembered across restarts in DATA_DIR/modules.json.
• Credentials are masked before a line is kept, shown or written: password=, secret=, token=, api-key= and authorization: values, the password in scheme://user:password@host, and bearer tokens. A module should still not log secrets; nothing can recognize every shape of one.

Route	Role	Purpose
GET /api/v1/runtime/modules/{id}/logs?level&search&instance&before&after&limit	engineer	Newest first; nextBefore pages
GET /api/v1/runtime/modules/{id}/logs/stream?level&after	engineer	Server-sent events: the backlog since after, then each line as it is written, with a keepalive every 15 seconds
GET /api/v1/runtime/modules/{id}/logs/download	engineer	The kept files, oldest first, as text
PUT /api/v1/runtime/modules/{id}/log-level	engineer	{level}

See Runtime and modules API.

The Diagnostics page

Open Gateway, then Diagnostics. The page starts with a strip of tiles: Memory, CPU, Modules (running and not running), Log problems (warnings and errors in the log) and Users (administrators and others). Below it, with a time range of 1 h, 6 h or 24 h:

• Memory: the process's memory In use and its Managed heap, trended from the @gateway.performance.memory and managedHeap tags.
• CPU and threads: CPU in percent of all processors, Threads and Busy pool threads.
• Log warnings and errors over time, with a link to Logs.
• Scheduled runs from the cron module over the last 24 hours (Succeeded, Failed, Skipped, Missed), when it is installed.
• Tag writes by outcome (Accepted, Refused, Failed), with a link to the audit log.

The same process figures appear as facts under Gateway settings, Performance (see Settings), read from GET /api/v1/admin/diagnostics (admin): memoryBytes, managedHeapBytes, cpuSeconds, threadCount, busyPoolThreads, processorCount, runtime, os.

Performance tags

@gateway.performance.* are real tags of kind system that the gateway creates at start and publishes every 10 seconds through the tag runtime. Unlike the other @gateway tags they have history like any tag, can carry alarms and can be trended on a screen. Nobody can edit, move, delete or write them.

Tag	Unit	Meaning
@gateway.performance.memory	MB	Memory the gateway process uses (working set)
@gateway.performance.managedHeap	MB	Memory held by .NET objects
@gateway.performance.cpu	%	CPU the gateway uses, of all processors
@gateway.performance.threads		Threads in the gateway process
@gateway.performance.busyPoolThreads		Thread pool threads at work

@gateway diagnostic tags

The other diagnostic tags live only in memory, are read-only and have no history:

Tag	Meaning
@gateway.version	The gateway's version
@gateway.uptime	Seconds since start (s)
@gateway.module.count	Installed modules
@gateway.module.<id>.{id,name,version,state,error}	Per module, with dots in the id replaced by _
@gateway.time, @gateway.tz	The gateway's clock (ISO-8601 in its zone, once a second) and its IANA zone. The clock is the one @gateway tag a replay produces
@gateway.connection.*	Driver and database connections; see Databases and storage
@gateway.clients.*	Live connections; see Clients

Names are lowercase. Until 2026-11-07 these were uptimeSeconds, moduleCount, timezone and modules.<id>.*; the old paths still answer and update but are no longer listed.

Health endpoint

GET /api/v1/runtime/health is the one runtime route that needs no session. An anonymous caller gets only {"status": "healthy"} or {"status": "unavailable"}, which says whether the event backbone (NATS JetStream) is connected. A signed-in caller also gets the module summaries. Point a container health check or an uptime monitor at it. See Runtime and modules API.

Limits

• The gateway log is not persisted by the gateway: 2,000 lines, in memory, cleared by a restart. Keep the container's console output if you need more.
• No log level setting for the gateway's own log from the dashboard; only modules have one.
• Performance history is as long as the historian keeps it; without the historian module the trends on Diagnostics reach back only as far as the event backbone's value retention.