Preparing PyroSync...
Loading the command surface and keeping your workspace state intact.
Status
GET /api/health on this deployment. Use ?format=prometheus for scraping.Last automated check: 2026-11-14 17:58 UTC
API and dashboard
The control-plane database answers.
Workspace data
The workspace database answers.
Job queue
Jobs start promptly.
Scraping workers
1 worker(s) heartbeating.
Status checks
Checks are running on schedule.
No active incidents.
No incidents in the history window.
Health. The status above comes straight from the health check. It reads operational when every configured database plane answers, and is re-checked every 30 seconds while this page is open.
Nobody sets component status by hand. An automated check runs every 1 minute(s). It probes the databases the same way GET /api/health does, and reads the job queue sampler and worker heartbeats. A status change only counts after 2 checks in a row agree, so a single blip does not open an incident.
Update cadence. An incident opens automatically when a component leaves operational, and gets an update whenever its impact changes. While it stays open, an update is posted at least every 30 minutes. It resolves automatically once the component recovers. If no check runs for 5 minutes, the page marks status as unknown, and records the gap as an incident when checks resume. Resolved incidents stay in the history for 90 days. Times are shown in UTC.
Every API endpoint belongs to one class, and each class has a p95 latency budget: at least 95% of calls must finish inside it. Latency is measured from the moment the server receives a call until it answers, so network time to and from you is not included. Each class is checked on the calendar month so far, platform-wide, once it has at least 100 calls.
| Class | p95 budget | Covers | Examples |
|---|---|---|---|
| Discovery and health | 100 ms | API root, OpenAPI documents, health checks | GET /api/v1, GET /api/v1/openapi.json, GET /api/health |
| Reads | 500 ms | GET of one resource or one list page | GET /api/v1/targets, GET /api/v1/jobs, GET /api/v1/crawl/{id} |
| Writes | 1,000 ms | Control-plane create, update and delete | POST /api/v1/scrape/credentials, DELETE /api/v1/crawl/{id}, POST /api/v1/crawl/{id}/pause |
| Job starts | 1,000 ms | Calls that queue work and return a job id; the work itself is not timed here | POST /api/v1/crawl, POST /api/v1/batch/scrape, POST /api/v1/extract/site, POST /api/v1/llms |
| Search and query | 2,500 ms | Search, warehouse queries and retrieval | POST /api/v1/search, POST /api/v1/queries, POST /api/v1/retrievals |
| Synchronous extraction | 10,000 ms | Calls that fetch and process a live page before answering | POST /api/v1/scrape, POST /api/v1/extract, POST /api/v1/map |
| Streams and downloads | Not latency-budgeted | Event streams and file downloads stay open by design, so they are watched for errors, not latency | GET /api/v1/crawl/{id}/events, GET /api/v1/llms/{id}/download |
A class over its budget raises a critical alert that names its slowest endpoints. A p95 that moves up a latency band from the previous month raises a regression warning, even while it is still inside the budget. Read-only synthetic probes also time the discovery and read classes against the live deployment.