Monitoring

Every app is observable the moment it’s live, with nothing to install. You look in the console; your coding agent reads the same data over MCP.

Resource usage

Live CPU and memory against the app’s allocation, as a 24-hour graph: usage versus the request floor and the limit ceiling. It shows whether an app is comfortable or hitting its ceiling, which is what you need to size a project. Your agent reads the same numbers with nyx_project_state.

Traffic

For every app that serves HTTP, the traffic panel tracks four numbers:

Traffic numbers are in the console only; there is no MCP tool for them yet. Watch error rate and p95 latency: a climbing error rate or a latency spike is usually the first sign of a regression, and because every deploy is on the record, you can line a spike up against the change that caused it.

Logs

For the detail behind a metric, read the app’s logs: the project’s Logs page in the console (live tail of one app), or nyx_app_logs from your agent, which returns structured, timestamped lines and handles a scaled-to-zero app cleanly. It’s also where you confirm a Job or CronJob did its work. Look for Exception, panic, Connection refused, OOMKilled, or a failing readiness probe.

Availability and operations

nyx_app_get with view: uptime returns daily availability, up to 90 days back. nyx_ops_events returns what the platform detected in the project and what it did about it. Every app’s image is also CVE-scanned automatically, see Security scanning.

Agent runs

If agents run in your project, nyx_runs lists their runs, newest first, each with status, duration, cost, and the platform’s one-word verdict (loop, budget80, baseline:2.1x). With run set to one of them, it opens that run step by step with its alerts and the project’s typical run for comparison. Both views tell you where a run went wrong; they store what each tool was called with, not what it returned, so read the error itself with nyx_app_logs.