Pixeltable Status & Reliability

This page summarizes the operational status of Pixeltable services and documents the error formats, rate limits, and retry behavior that agents and developers should rely on. For real-time incident updates, follow the channels listed below.

Current status

Website (pixeltable.com)Operational
Documentation (docs.pixeltable.com)Operational
Pixeltable Cloud control planeOperational
Ask endpoint (/ask) and WebMCP (/mcp)Operational

Status reflects the most recent operational review. For live incident reports and maintenance notices, subscribe via the channels below.

Incident channels

Discord: discord.gg/QPyqFYx2UN (real-time updates and support)
Email: [email protected] (report an incident or degraded service)
GitHub: github.com/pixeltable/pixeltable/issues (library bugs)

Error handling for agents

API and agent endpoints return structured JSON errors with an actionable message. Example shape:

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests. Retry after the indicated delay.",
    "status": 429,
    "retryable": true
  }
}

HTTP status codes follow standard semantics: 400 invalid request, 401 authentication required, 403 forbidden, 404 not found, 429 rate limited, 5xx transient server error.

Rate limits & retry guidance

The public /ask endpoint is limited to 20 requests per minute per IP. Exceeding it returns 429.
On 429 or 5xx, retry with exponential backoff: start at ~1s and double each attempt (1s, 2s, 4s, 8s), capped at ~30s, with jitter. Stop after 5 attempts.
Treat 4xx other than 429 as non-retryable; fix the request instead of retrying.
Once the public REST API ships, mutating requests will support an Idempotency-Key header so retries are safe.