Additional utilities

Additional utilities brings together the fast operational helpers teams reach for when they need an immediate sanity check on the instance rather than a full module workflow. This is where you inspect current machine health, run a network speed test, clear accumulated process and SRT errors, or resolve an IP into a location signal.

These endpoints matter when the team is trying to answer a practical question quickly: is the box under pressure, is the uplink good enough, are old error logs obscuring what is happening now, or where is this remote endpoint likely coming from.

Examples by preset

The useful patterns here are simple: capture a health snapshot before or during an incident, verify network throughput on the live host, clear stale error noise before a new test, and resolve an IP when a team needs location context during troubleshooting.

{
  "ip": "1.1.1.1"
}

Workflow examples

Take a quick machine-health snapshot before blaming the transport layer

Use getStat when the first question is whether CPU, RAM, disk, or accumulated process errors already explain what the team is seeing.

Verify the uplink before a live event or after a connectivity complaint

Use speedTest when operators need one immediate read on upload, download, and latency from the same host that runs the engine.

Reset noisy error history before the next validation cycle

Use clearErrorLogs when old process or SRT errors should not pollute the next test, rehearsal, or recovery pass.

Get utility stat
Collapse
POST
/api/utils/getStat

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
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

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

Versioning
publicVersion
array

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

Error visibility
srtErrors / processErrors
array

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

Operation result
success
boolean

Successful responses expose success: true.

Response: Get utility stat
JSON
{
  "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
}
Run speed test
Expand
POST
/api/utils/speedTest

Use this method when operators need a direct read on upload, download, and latency from the engine host itself. It is especially useful before a live window or after a complaint that sounds network-related.

Request body parameters
This method has no parameters
Run speed test
curl --request POST \
  --url http://localhost/api/utils/speedTest \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{}'
Response
Latency
ping.jitter / ping.latency
mixed

Round-trip quality signals returned by the speed test.

Throughput
download / upload
object

Measured transfer performance of the current host.

Network context
packetLoss / isp / timestamp
mixed

Extra context about the network path used during the test.

Operation result
success
boolean

Successful responses expose success: true.

Response: Run speed test
JSON
{
  "timestamp": "2026-03-24T19:30:00.000Z",
  "ping": {
    "jitter": 0.5,
    "latency": 2.1
  },
  "download": {
    "bandwidth": 291944,
    "bytes": 3036488,
    "elapsed": 10604
  },
  "upload": {
    "bandwidth": 262287,
    "bytes": 1838732,
    "elapsed": 6905
  },
  "packetLoss": 0,
  "isp": "Awesome ISP provider",
  "success": true
}
Clear error logs
Expand
POST
/api/utils/clearErrorLogs

Use this method when the error history should be cleared before a new test or recovery cycle so fresh issues are easier to isolate.

Request body parameters
This method has no parameters
Clear error logs
curl --request POST \
  --url http://localhost/api/utils/clearErrorLogs \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{}'
Response
success
boolean

The backend confirms that both process and SRT error buffers were cleared.

Response: Clear error logs
JSON
{
  "success": true
}
Get location by IP
Expand
POST
/api/utils/getLocation

Use this method when the team needs quick geographic context for a remote endpoint or IP address during troubleshooting, access review, or incident triage.

Request body parameters
ip
string

IPv4 address that should be resolved into a lightweight geographic hint.

Get location by IP
curl --request POST \
  --url http://localhost/api/utils/getLocation \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "ip": "1.1.1.1"
}'
Response
country / timezone / city / ll / area
mixed

Location metadata returned for the requested IP address.

Response: Get location by IP
JSON
{
  "range": [
    16843008,
    16843263
  ],
  "country": "AU",
  "timezone": "Australia/Sydney",
  "city": "",
  "ll": [
    -33.494,
    143.2104
  ],
  "area": 1000
}
Back toCluster nodesNext toCallaba Engine documentation