Service status¶
AzScraper does not yet publish a separate public status page. Use the API health endpoint and your own monitoring to confirm the service is reachable.
Health check endpoint¶
GET /health — no authentication required.
Healthy (HTTP 200)
{
"status": "ok",
"info": {
"api": { "status": "up" },
"mongo": { "status": "up" }
},
"error": {},
"details": {
"api": { "status": "up" },
"mongo": { "status": "up" }
}
}
When MongoDB is not configured in an environment, the mongo indicator may be omitted.
Degraded (HTTP 503)
{
"status": "error",
"info": { "api": { "status": "up" } },
"error": { "mongo": { "status": "down", "message": "..." } },
"details": { "api": { "status": "up" }, "mongo": { "status": "down", "message": "..." } }
}
Load balancers and uptime monitors should treat HTTP 200 with "status": "ok" as healthy and 503 as unhealthy.
What the health check covers¶
| Indicator | Meaning |
|---|---|
api |
API process is running |
mongo |
MongoDB ping succeeds (when configured) |
The health endpoint does not verify worker queue depth, individual crawl success rates, or third-party payment providers. Job failures are reflected per job status in the dashboard and API, not in /health.
During an incident¶
- Confirm
/healthfrom your region or monitoring tool. - Check whether failures are isolated to specific job types (search vs details) or marketplaces.
- Pause new job creation if credits are being consumed on failing runs; use Cancel on stuck jobs where available.
- Contact support through your account channel if degradation persists.
Future status page
A dedicated status page may be added later. Until then, /health is the authoritative liveness probe documented here and in Get data — Health.
Related¶
- Error taxonomy — interpret API error codes during outages
- Rate limits & concurrency — throttling vs platform incidents
Tiếng Việt: Trạng thái dịch vụ (VI)