Most production incidents on a newly started node come down to a fact that was settled at boot and never shown: the wrong configuration database, a cluster group left empty, a mail relay that accepts the connection and refuses to send. This release makes the startup report the first diagnostic an operator reads, and adds a console for acting on what it shows.
A startup report an operator can act on
- Grouped and complete. The report is organised into sections, and each one states what was found and what was missing, instead of a list of counts.
- Configuration and cluster. The configuration database and what it is, the cache strategy, the cluster group the node joins, where the process writes and which ports are open.
- Security. Transport, CSRF protection, the authenticators configured per context, two-factor status, content security policy and response headers.
- Verified, not just configured. Mail is checked against the relay itself, every Redis server in use reports its health, and every microservice in the group is probed, so a node that cannot send a two-factor code says so at startup.
- Services and fixtures. Background daemons are listed beside the services that declare them, the MCP section states whether the node admits connections, and the report lists which fixtures were restored or repaired.
An in-process admin console
- No client to install. An optional console, disabled by default and bound to the local interface, renders a full-screen terminal interface inside the server that any standard telnet client can open.
- Operations when something changed outside the normal path. Menus cover users, caches and their sizes, connection pools and diagnostics, including clearing a single cache or reloading one dictionary.
- Redis statistics. Per-server command and connection statistics are published through JMX, alongside the console.
Both are for the operator on the machine. The console is off unless configured, and nothing in the report is exposed to application users.