Monitoring — overview
| Surface | Shows | For |
|---|---|---|
| The Monitoring page | What happens now: connected users, record locks, database pools, runtime, the live log. | Superusers, from Liberty Next → Operate → Monitoring. See The Monitoring page. |
| Server log and Retention | Every line the server wrote, searchable; what the server keeps and how much it takes. | Superusers, the other two tabs of the Monitoring page. See Server log and Retention. |
| Health endpoints | /health (the process is up), /ready (the framework database answers), /info (version and counts). | Load balancers, container healthchecks, external probes. See Health endpoints. |
./liberty status / doctor | Versions, health, pending migrations, configuration problems. | Administrators on the server. See Operations. |
What to look at
| Situation | First check |
|---|---|
| Users find the application slow | Database pools: connections all In use, or Overflow above 0. |
| An error on a screen | The server log searched for the request id the user's message gives. |
| The disk fills up | Retention: the size of each store, then Preview and Run now. |
| A record cannot be saved | Record locks: someone else may have it open. |
| The server seems stuck | /ready, then ./liberty status. |
| A scheduled job did not run | The Nomaflow run history — a MISSED run records it. |
What it does not show
The Monitoring page is a live view kept in the server's memory: a restart empties it. For history — response times, database load, container resources — use the tools made for it (an APM, the database's own statistics, docker stats). The server's log goes to standard output: log_format = "json" in [app] makes it easy to collect, and each line carries the request id.