System status
Live health for Tyxter Messaging infrastructure. Component data is read from the public GET /status endpoint.
All systems operational
Last checked .
Measured uptime 99.1% over the last 90 days, externally probed from outside this infrastructure, measuring since Aug 3, 2026. Responses that answered while degraded count as reachable. The day-by-day history is on the Tyxter status page.
Components
Postgres
Durable source of truth for messages, billing, and configuration.
Redis / BullMQ
Queue execution and short-lived operational coordination.
Incidents
No incidents published
The component health above is read live from GET /statuson every request, so it answers “is it healthy right now” — it is not a history. Incidents are published separately, to the Tyxter status page: active ones stay listed while they are being investigated, identified, or monitored, and recent resolved ones stay visible as history. That feed is the record, and nothing is published to it right now.
Something not explained by live component health or by the incident feed is worth telling us about before it reaches either. An integrating agent can report it with POST /v1/feedback — the Feedback API reference has the request shape — carrying the trace_id from the failing response; a human can use the contact link in the footer. What to expect back, and what Tyxter does and does not promise about uptime, is on Support & service levels.
What keeps a failure from becoming data loss — the source-of-truth model behind these components, and how the database is backed up — is on the Trust & security page.
API shape
{
"object": "status",
"status": "healthy",
"time": "2026-05-05T12:00:00.000Z",
"components": {
"db": "healthy",
"redis": "healthy"
},
"version": "1.0.0"
}