/api/v1/statusCurrent health status of all monitored services with 30-day and 90-day uptime percentages.
Current health status of all monitored services with 30-day and 90-day uptime percentages.
freeSince v2.1.0
Why use this
Public service-health probe — current operational status of every FinRadar service (main_api, insider_module, 13f_worker, postgres_db, redis, etc.) with rolling 30-day and 90-day uptime percentages. Also includes data-freshness metrics (last filing accepted, queue depth, last 13F batch parsed) so customers can verify ingestion is current BEFORE making decisions on the underlying data — a green status with `last_filing_at` 12 hours stale is misleading without this layer. No authentication required, free (`cost: 0`). The right endpoint for: status pages, monitoring dashboards, operational alerting integrations, and pre-flight checks on automation pipelines. Pair with `/api/v1/status/history` for time-bucketed historical uptime charts.
Common use case
Building a status page or monitoring dashboard that shows service health at a glance.
Public health probe — current status of every FinRadar service with rolling 30-day uptime %. Includes data-freshness metrics (last filing accepted, queue depth, last 13F batch) so customers can verify ingestion is current before making decisions on the data. No auth required, cost: 0. Pair with GET /api/v1/status/history for time-bucketed historical uptime charts.
Response schema
| Field | Type | Nullable | Description |
|---|---|---|---|
| overall | string | no | Aggregate platform-wide status — `operational` (all services healthy), `degraded` (one or more services show elevated latency but functional), `partial_outage` (one or more services down but most operational), `major_outage` (multiple services down). Use as the canonical 'is FinRadar healthy?' single-field signal. Color-code dashboards accordingly (green/amber/orange/red). |
| services | array | no | Array of per-service status entries. Covers ~10-15 monitored services: `main_api`, `insider_module`, `13f_worker`, `postgres_db`, `redis`, `sec_gateway`, `sec_watchdog`, etc. Each row carries response time, uptime stats, and last-check timestamp. |
| services[].name | string | no | Canonical service identifier (e.g. `main_api`, `insider_module`, `13f_worker`, `postgres_db`, `redis`, `sec_gateway`). Stable across versions — safe for use as join key in monitoring integrations. |
| services[].status | string | no | Per-service status — `operational` (healthy), `degraded` (elevated latency but functional, typically > p95 latency threshold), `down` (failing health check). Watchdog runs the check every 60 seconds; values reflect the most-recent successful check. |
| services[].uptime_30d_pct | number | no | Rolling 30-day uptime percentage (0.0-100.0, computed as `healthy_checks / total_checks * 100`). Internal SLO target is 99.9% on customer-facing services. Values below 99.5% should trigger reliability investigation. |
| services[].last_check_at | string | no | ISO-8601 UTC timestamp of the most recent watchdog health check. Should always be within the last 60 seconds — values older than 5 minutes indicate the watchdog itself is degraded (a meta-failure that bypasses normal alerting). |
| data_freshness | object | no | Data-freshness metrics complementing service-uptime: `{ last_filing_at, queue_depth, last_13f_batch_at, last_xbrl_run_at, last_news_at }`. Use to detect ingestion staleness even when services are technically 'up'. A `last_filing_at` more than 10 minutes stale during ET market hours is the canonical ingestion-pipeline alert. |
| as_of | string | no | ISO-8601 UTC timestamp the status snapshot was generated server-side. Cached for 30 seconds at the gateway — polling more aggressively than 1 Hz returns stale-but-cheap data. |
Sample response
·
- "status": "operational"
- "services":
- "main_api":
- "postgres_db":
- "redis":
- "checked_at": "2026-03-14T12:00:00Z"
Errors
| Status | Label | Description |
|---|---|---|
| 200 | OK | Request succeeded. |
| 400 | Bad Request | Invalid query, body, or path parameter. |
| 401 | Unauthorized | Missing or invalid Authorization header / api_Token. |
| 402 | Payment Required | Insufficient token balance for this call. Top up |
| 429 | Too Many Requests | Rate limit exceeded for your tier (see /pricing for tier limits). Tier limits |
| 500 | Server Error | Unexpected server-side failure. Retry with backoff; report if persistent. |
Code samples
curl "https://api.finradar.ai/api/v1/status" \
-H "Authorization: Bearer YOUR_JWT_TOKEN"Generate an API key in /account/credentials to run live queries (literal YOUR_API_KEY placeholder shown until then).