Metrics & Processes

Watching your app's CPU, memory, network, disk, and storage live and over time, reading the sizing hints, and inspecting the processes inside each replica.

Fri Oct 02 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Raklane measures the resources every replica of your app uses, wherever it runs — on Raklane's managed compute or on your own BYOC server. There's nothing to install or configure in your app: no agent library, no exporter, no code changes.

You'll find two tabs on every app:

Metrics — usage right now, usage over time, and a per-replica breakdown, with plain-language hints on whether your app is sized right.
Processes — a live, Activity Monitor-style list of the processes running inside each replica.

What's measured

Resource	What you see	Why it matters
CPU	CPU used, in cores (millicores), against the replica's CPU limit	High usage near the limit means slower responses.
CPU throttling	The share of scheduling periods in which the app hit its CPU limit and had to wait	The clearest sign that the CPU limit is too low.
Memory	Working set — the memory that counts against the limit — against the replica's memory limit	Past 100% of the limit, the process is killed.
OOM kills	How many times a process was killed for running out of memory since the replica started	Any non-zero number deserves a look.
Network	Bytes per second in (↓) and out (↑)	Traffic levels and unexpected spikes.
Disk I/O	Bytes per second read and written	Heavy disk activity can slow everything down.
Storage	Size of files written inside the container (measured every few minutes)	Files written here grow until the storage limit, and are lost when the replica is replaced.
Processes	Number of processes in each replica	A climbing count can mean a process leak.

Numbers are per replica, and the totals add up all running replicas.

The Metrics tab

Right now

The top of the page shows current totals for CPU, memory, network, disk I/O, and storage. Where you've set a limit, CPU and memory are shown against it; with no limit, the tile says so (CPU: no limit set). Live values refresh about every 15 seconds.

Sizing hints

Below the live numbers, Raklane adds advice when your app's usage suggests a change:

Hint	When it appears	What to do
Out of memory	A process in the app has been killed for exceeding its memory limit	Raise the memory limit, or look for a memory leak (the Processes tab shows what's using memory).
Memory is close to the limit	Memory is at 90% or more of the limit	Raise the limit before it turns into an out-of-memory kill.
CPU is being throttled	25% or more of scheduling periods hit the CPU limit	Raise the CPU limit — throttling shows up as slower responses.
Plenty of headroom	CPU under 10% and memory under 25% of their limits	If that holds over a day or more, a smaller size costs less.

Change limits from the app's Resources page — no redeploy needed (see Deploying Your App).

History

Charts of the same resources over time: CPU, Memory, Network, Disk I/O, CPU throttling, and Running replicas. Pick a range: 15m, 1h, 6h, 24h, 7d, or 30d. Short ranges refresh with the live values; longer ones refresh every minute.

History is kept for 30 days by default. If you see "Usage history isn't enabled on this Raklane installation yet", your installation hasn't turned on history storage — live values and processes still work. Ask whoever operates your installation.

Replicas

A table with one row per running replica: CPU and memory against their limits, network and disk rates, process count, and OOM kills. Use it to spot one misbehaving replica among several healthy ones.

The Processes tab

The Processes tab lists every process running inside each of your app's replicas, much like Activity Monitor or top:

Column	Meaning
Replica	Which replica the process is running in.
PID	The process ID inside the container.
Process	The process name. Hover it to see its full command line.
CPU	Current CPU usage.
Memory	Current memory usage.
Disk read / Disk write	Current disk I/O rates.
Threads	Number of threads.
User	The user the process runs as.

Sort by CPU, Memory, or Disk I/O to find the heaviest process quickly.
Refresh every 5s keeps the list live; turn it off to freeze a snapshot while you read it. The time it was sampled is shown next to the controls.
The list is live only. Raklane takes a sample when you look and doesn't keep process history. To see trends, use the Metrics tab.
If no replicas are running (the app is paused or was never deployed), there's nothing to list — deploy or resume the app first.

Network traffic isn't shown per process, because Linux doesn't track it that way. Network traffic per replica, on the Metrics tab, is exact.

How it works

Each server that runs your app collects usage for its containers about every 15 seconds and reports it to Raklane:

No extra ports. Reports travel over the same encrypted connection the server already uses. A BYOC server still needs no inbound port.
Short outages don't create gaps. If the connection drops, the server holds on to up to about 10 minutes of reports and sends them once it reconnects.
Raklane decides whose data it is. Which app a container belongs to comes from Raklane's own records, never from the server's report — so a misbehaving server can't make its numbers show up under someone else's app.

Privacy and access

You see only your own apps. Metrics and process lists are scoped to your app's own containers; there's no way to query another customer's data.
Your environment variables are never read. Process lists never look at a process's environment, where injected secrets live. Command lines are truncated to 512 characters.
Your BYOC server stays yours. Raklane's operators can see server-level usage figures (CPU, memory, disk, network) for every server that reports metrics, including BYOC servers, to keep the platform healthy. They can't browse the process list of a server you own — that's only possible on Raklane's own servers.
Metrics don't affect your bill. Billing is based on the resources you configure (or your subscription, or the BYOC fee), not on these measurements. Losing metrics history never changes what you pay.

Metrics on a BYOC server

Everything above works the same for apps on your own server. Two settings on the server's Node Agent affect it:

RAKLANE_AGENT_METRICS_INTERVAL (default 15s) — how often the server reports. A longer interval sends less data but makes charts coarser. Setting it to 0 stops reporting entirely, and your apps' Metrics tab on that server goes empty. The Processes tab still works, because it's sampled on request.
RAKLANE_DATABASE_VOLUME_ROOT — where database data is stored, and where its disk usage is measured.

See BYOC Agent Configuration.

If your BYOC server is Offline, live values for its apps stop updating until it reconnects, and the reports it buffered are then sent in one go.

Troubleshooting

The Metrics tab is empty. Check the app has running replicas (Status page). Right after a deploy, give it 15–30 seconds for the first reports to arrive. On a BYOC server, check the server is Healthy and that RAKLANE_AGENT_METRICS_INTERVAL isn't 0.

History says it isn't enabled. History storage is turned off on your installation. Live values and processes still work.

Memory looks lower than my app reports internally. The Memory figure is the working set — what counts toward the limit. Your runtime may report heap size, reserved memory, or virtual memory, which are measured differently.

CPU is low but the app is slow. Check CPU throttling rather than average CPU: short bursts can hit the limit even when the average looks low. Also check Disk I/O, and your app's own logs for slow calls to databases or external services.

Storage keeps growing. Something is writing files inside the container — logs written to disk, uploads, a cache. Those files are lost when the replica is replaced. Write logs to stdout, and store durable data in a database or external storage.