Pixeltable Status & Reliability

All systems operational

Last checked Aug 18, 2026, 1:56 AM UTC · refreshed about once a minute

• Website and dashboard

  Operational

• Authentication

  All Systems Operational

  Operational

• Control plane

  Operational

• HTTP services

  https://asiegel-cloud.pxt.run/health (liveness only)

  Operational

• Catalog and cloud tables

  Same check as HTTP services until STATUS_CANARY_CATALOG_HOST is set

  Operational

Incidents

No incidents posted.

Incident channels

• Discord: discord.gg/QPyqFYx2UN (real-time updates and support — use this if the website is down)
• Email: contact@pixeltable.com (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.