media server logo
Toggle documentation navigation
Callaba home

Additional utilities

Use Additional utilities to inspect instance health, test network throughput, look up an IP location, and clear collected error logs.

What it doesRun an operational check

Choose this whenYou need host health, bandwidth, IP-location, or error-log diagnostics.

Use another module whenUse the owning media module's statistics when the question is about one stream or process.

1Choose a utility2Run the check3Use the result
POST /api/utils/getStat
4 endpoints

Before you start

getLocation is a public read method. Statistics, bandwidth tests, and log cleanup require a valid x-access-token. Run tests and cleanup only from trusted operational tooling because they can consume resources or remove diagnostic evidence.

What you can do

  • getStat reads available instance statistics.
  • speedTest measures network throughput from the instance.
  • getLocation returns the detected instance location.
  • clearErrorLogs clears accumulated error logs.

Example workflow

  1. Read current statistics before changing the workload.
  2. Run a speed test outside the live production window.
  3. Compare the result with expected ingest and egress bitrate.
  4. Export required incident evidence before clearing logs.

Common use cases

  • Validate a new regional host before routing a live event to it.
  • Investigate whether network capacity explains stream instability.
  • Confirm the detected region before assigning customer workloads.

Limits and troubleshooting

A speed test measures the current path and can compete with live traffic; it is not a guaranteed capacity value. Location is an operational hint rather than precise physical geolocation. Clearing logs is irreversible, so preserve any evidence needed for support first.

Next steps

Use the result to adjust deployment capacity, network policy, or the affected media module.

REST solution recipe

Preflight an instance network before a live event

Resolve the public location signal and run a speed test as one part of deployment validation before connecting live sources.

  1. Confirm public locationUse the resolved address data to catch an unexpected deployment region.POST /api/utils/getLocation
  2. Run the preflight testRecord the result beside the real SRT or RTMP path test.POST /api/utils/speedTest

A speed test is a point-in-time signal, not a capacity guarantee. Validate sustained throughput, packet loss, latency, and the real media path.

POST
/api/utils/getStat
API token required

Use this method for a fast instance-health snapshot. It is the quickest way to see CPU, RAM, disk, public version context, and accumulated process or SRT errors before the team goes deeper into module-specific debugging.

Request body parameters
This method has no parameters
Get utility stat
Copy code
curl --request POST \
--url http://localhost/api/utils/getStat \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{}'
Response
Machine health
cpuUsage / drive / RAM
mixed
Copy direct link

Current CPU, disk, and memory snapshot for the engine host.

Versioning
publicVersion
array
Copy direct link

Published version metadata used by the dashboard to compare the local build with available public versions.

Error visibility
srtErrors / processErrors
array
Copy direct link

Current accumulated SRT and process-error sets that operations can review before clearing them.

Operation result
success
boolean
Copy direct link

Successful responses expose success: true.

Response: Get utility stat
JSON
Copy code
{
"cpuUsage": 12.4,
"drive": {
"totalGb": "250.00",
"usedGb": "81.00",
"usedPercentage": "32.4"
},
"RAM": {
"totalMemMb": 16384,
"usedMemMb": 6240,
"usedMemPercentage": 38.1
},
"publicVersion": [
{
"version_name": "stable",
"version_number": "8.2"
}
],
"srtErrors": [],
"processErrors": [],
"success": true
}
POST
/api/utils/speedTest
API token required
POST
/api/utils/clearErrorLogs
API token required
POST
/api/utils/getLocation
Public endpoint