Service Status

The status page summarizes platform health signals, queue posture, and recent runtime quality indicators. Use it to confirm whether failures are isolated to your target or platform-wide.

What to check first

How to interpret status metrics

Operational follow-up

  1. Validate platform status before escalating target-specific incidents.
  2. Compare your run timestamps with visible health window metrics.
  3. Re-run diagnostics after queue or dependency recovery to confirm normalization.

FAQ

Does green status guarantee every target works?

No. Status reflects platform health, not correctness of every external endpoint tested.

Why can queue depth be null?

Queue depth is shown when supported by the active backend and permissions.

Should I trust one status snapshot?

Use trend windows and repeated checks for stronger incident decisions.

Can runtime spikes happen without failures?

Yes. Dependency latency can increase runtime before hard failure thresholds are reached.

Where can I see deeper operational analytics?

Authorized operators can use the admin dashboard for extended metrics and event views.

Runtime status metrics

Window start

2026-02-10T00:21:34+00:00

Queue connection

database

Queue depth

n/a

Cache store

database

Redis reachable

Yes

Run count (last hour)

2

Average runtime (ms)

544

Run statuses

{
    "succeeded": 2
}

Tool uptime (last hour)

[
    {
        "tool_key": "dns.nslookup",
        "total_runs": 1,
        "succeeded_runs": 1,
        "failed_runs": 0,
        "success_rate_percent": 100
    },
    {
        "tool_key": "dns.reverse-dns",
        "total_runs": 1,
        "succeeded_runs": 1,
        "failed_runs": 0,
        "success_rate_percent": 100
    }
]

Probe metrics (last hour)

{
    "active_probes": 0,
    "recently_seen_probes": 0,
    "results_last_hour": 0,
    "average_runtime_ms": 0,
    "success_rate_percent": 0
}