API Analyst — overview

The API Analyst is an admin-only console for the SAGRIS data API — check that every service is alive, send test requests, watch live load, and benchmark endpoints. It runs server-side probes, so it can reach the localhost-bound services your browser can't.

The panels

This panel: service health

• Service health — one row per SAGRIS service with its liveness. Click ↻ Refresh to re-probe.
• Host snapshot — current CPU, memory, and load on the API host.

Note: The probe runs from the API process itself, which is why it can report on the internal 127.0.0.1 services that aren't exposed to the browser.

Endpoint tester

A request workbench for the data API. Send a real request to any of the endpoints and inspect the status, latency, payload size, and response body.

API key

• Public endpoints (e.g. /api/health, /api/stats) need no key.
• The rest require a data-API key sent as the X-API-Key header.

Paste your key into the data-API key field — it's kept only in this tab's sessionStorage. The key-state indicator shows whether key-gated calls will succeed.

Sending a request

1. Paste your X-API-Key (for gated endpoints).
2. Find the endpoint in the list.
3. Edit its path and/or request body inline if needed.
4. Send, then read the status, timing, size, and response.

What to watch

• A slow response usually points at a heavy dc.load() (large bbox or long time range).
• A 401/403 means the key is missing, wrong, or lacks the plan feature for that endpoint.

Tip: Use this to reproduce a user's failing call exactly — same path, same body, your key — before digging into logs.

System load

A live view of how hard the API host is working and which endpoints are busy.

Host

CPU, memory, and load average for the API host, refreshed every 4 seconds (toggle auto-refresh 4s off to pause). The note line reports the state of the in-memory request buffer.

Endpoint activity

Per-endpoint request stats from an in-memory ring buffer shared across workers:

• a latency sparkline of the most recent calls (low → high),
• p50 / p95 latency,
• error counts,
• ordered by most-recent activity.

Note: The ring buffer holds only the most recent requests and is lost on restart — it's a live diagnostic, not a historical log. For history, use the Manager's Log Analyst.

Reading it

• A rising p95 with a flat p50 means occasional slow calls — often big dc.load() requests.
• Climbing host CPU/memory under steady traffic can indicate a leak or an expensive endpoint; cross-check which endpoint is most active.

Benchmark

Fire a batch of requests at a single endpoint with a chosen concurrency, and get p50 / p95 / max latency and throughput — the quickest way to spot dc.load() slowdowns or confirm a fix.

Running a benchmark

1. Choose the endpoint.
2. Set the number of requests (N) and the concurrency.
3. Run, and read the latency percentiles and throughput.

Be considerate

This sends real load to a live service. Default to a light, cached endpoint:

Heavier data endpoints use your API key and the request body from the tester, so set those up there first. Keep N and concurrency modest on data endpoints to avoid impacting real users.

Tip: Benchmark before and after a change to the same endpoint with the same N/concurrency — the p95 delta tells you whether the change actually helped.