When an Akan app feels slow or does not respond, start with two runtime endpoints. Health tells you whether the app is alive, and metrics tells you how busy it is.
`/_akan/app/health` checks gateway and child process status.
`/_akan/app/metrics` checks requests, sockets, rooms, and memory.
Use logs after metrics when you need the reason behind the numbers.
Check Health
Use health first when the app does not open. It shows whether the gateway is running and whether child servers are ready.
Health endpoint
Simplified response
Check Metrics
Use metrics when the app is alive but feels busy. It gives a quick picture of traffic, WebSocket load, rooms, and process memory.
Metrics endpoint
Simplified response
How To Read
`activeRequests` means requests currently being handled. If it stays high, a slow endpoint may be blocking work.
`activeWebSockets` and `rooms` help you understand realtime connection load.
`rssBytes` and `heapUsedBytes` show memory size. Watch the trend, not only one snapshot.
`rscPendingRenderCount` can hint that server rendering work is queued or waiting.
Memory Logs
When a memory issue is hard to catch from one metrics response, turn on periodic memory logs and watch how the values change over time.
Useful env
`AKAN_MEMORY_LOG=1` prints memory summaries periodically.
`AKAN_MEMORY_LOG_INTERVAL_MS` changes the report interval.
`AKAN_MEMORY_GC_ON_REPORT=1` runs GC before reporting, useful for diagnosis.
Troubleshooting Order
Open health. If a child is not ready or unhealthy, fix startup first.
Open metrics. Check active requests, sockets, rooms, and memory.
If memory keeps growing, enable memory logs and compare several samples.
Use app logs to find which endpoint, queue, or render path caused the numbers.
