Additional utilities
Use Additional utilities to inspect instance health, test network throughput, look up an IP location, and clear collected error logs.
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.
/api/utils/getStatBefore 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
getStatreads available instance statistics.speedTestmeasures network throughput from the instance.getLocationreturns the detected instance location.clearErrorLogsclears accumulated error logs.
Example workflow
- Read current statistics before changing the workload.
- Run a speed test outside the live production window.
- Compare the result with expected ingest and egress bitrate.
- 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.
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.
- Confirm public locationUse the resolved address data to catch an unexpected deployment region.
POST /api/utils/getLocation - 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.
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.
Current CPU, disk, and memory snapshot for the engine host.
Published version metadata used by the dashboard to compare the local build with available public versions.
Current accumulated SRT and process-error sets that operations can review before clearing them.
Successful responses expose success: true.