Metrics and transfer
Inspect 24-hour performance data and manage who can read it.
Open a server's Metrics tab to see its last 24 hours of CPU, memory, disk and public network activity. Monthly transfer is a separate reading; it is not the same as current network speed.
Read metrics through the API
curl -sS "$BASE/v1/vms/$VPS_ID/metrics" \
-H "Authorization: Bearer $LAYERBEAT_API_KEY"Samples cover a rolling 24-hour window at 300-second intervals. A snapshot is cached for five minutes. Repeated requests reuse that snapshot while it is fresh, but authorization is checked on every request.
Each series reports unit, available, stale, latest_at and timestamped points. Missing samples are omitted, not replaced with zero. If no data is available, available is false and points is empty. A stale value may not represent the server's current activity.
The collection window ends slightly in the past to allow metrics to arrive. These values are aggregated samples, rather than instantaneous measurements.
Grant access
Owner/admin sessions can read metrics automatically. Other member sessions need an explicit server grant. Every API key, including an owner's key, needs vm:read and an explicit grant.
An owner/admin can edit the access list on the server page or use PUT /v1/vms/{id}/metrics/access with a session:
{
"user_ids": ["usr_YOUR_MEMBER_ID"],
"api_key_ids": ["key_YOUR_API_KEY_ID"]
}Use actual IDs from your workspace. Both arrays are required, and the request replaces the entire explicit list. Empty arrays revoke all explicit grants; automatic owner/admin session access remains. API keys cannot change these grants.
The total limit is 100 grants. Foreign, removed or inactive recipients are rejected without changing the existing list. An ungranted caller receives 404 even when metric data is cached.
Read monthly transfer
curl -sS "$BASE/v1/vms/$VPS_ID/traffic" \
-H "Authorization: Bearer $LAYERBEAT_API_KEY"Compare the reported usage with the plan's included transfer. For connection issues, also inspect firewall rules.