Reliability & operations
HansaChat system status.
Live availability, measured uptime, and every recorded incident — checked by an independent external monitor every five minutes.
- Chat uptime, last 30 days
- 99.9%
- Chat uptime, last 90 days
- 99.95%
- Availability target
- 99.9% monthly
- Monitoring
- Independent, every 5 minutes
Current status
Every core service, checked every five minutes.
The monitor calls the chat health endpoint and the public website directly and records the result of each core service separately.
Last check: 22:50 UTC · 552 ms response time
- Chat API Operational
- Database Operational
- Cache Operational
- Message queue Operational
- Realtime Operational
- Website Operational
Measured uptime
Ninety days of measurements, day by day.
Each bar is one day. Availability is the share of five-minute checks that succeeded — measured by the external monitor, not by HansaChat itself. The service level agreement evaluates the availability target per calendar month; the daily bars show rolling 30- and 90-day windows for continuous visibility.
Chat service
30 days: 99.9% 90 days: 99.95%
8,595 checks in 30 days
Website
30 days: 99.91% 90 days: 99.95%
Incident history
Every recorded incident, with post-mortems.
Incidents are opened automatically after three consecutive failed checks and closed when the next check succeeds. Significant incidents receive a published post-mortem.
-
Resolved Website Sep 29, 2026, 08:00 UTC · 24m 50s
HansaChat Status Alert Landing Page has been DOWN for 3 consecutive checks. Affected services: Landing Page Last error: HTTP 504 Time: 2026-09-29T08:00:39.412Z
Post-mortem
Summary On 2026-09-29 both the chat API and the landing page were unavailable for about 30 minutes. Automated 5-minute checks recorded continuous HTTP 502/504 gateway failures between 07:50 and 08:25 UTC. Root cause An IONOS Cloud incident: partial connectivity degradation to the control plane affecting Kubernetes operations. See https://status.ionos.cloud/incidents/zprjxl2b1kmy for details. No defect in HansaChat application code was involved. Impact Around 30 minutes of downtime for both the chat API and the landing page; all incoming requests failed with HTTP 502/504 gateway errors. Resolution Service recovered automatically once the IONOS incident ended. Monitoring confirmed full recovery at 08:25 UTC; no HansaChat-side intervention was required.
-
Resolved Chat service Sep 29, 2026, 08:00 UTC · 24m 49s
HansaChat Status Alert Chat service has been DOWN for 3 consecutive checks. Affected services: Chat API Last error: HTTP 504 Time: 2026-09-29T08:00:38.344Z
Post-mortem
Summary On 2026-09-29 both the chat API and the landing page were unavailable for about 30 minutes. Automated 5-minute checks recorded continuous HTTP 502/504 gateway failures between 07:50 and 08:25 UTC. Root cause An IONOS Cloud incident: partial connectivity degradation to the control plane affecting Kubernetes operations. See https://status.ionos.cloud/incidents/zprjxl2b1kmy for details. No defect in HansaChat application code was involved. Impact Around 30 minutes of downtime for both the chat API and the landing page; all incoming requests failed with HTTP 502/504 gateway errors. Resolution Service recovered automatically once the IONOS incident ended. Monitoring confirmed full recovery at 08:25 UTC; no HansaChat-side intervention was required.
-
Resolved Chat service Sep 2, 2026, 09:15 UTC · 5m
HansaChat Status Alert Chat service has been DOWN for 3 consecutive checks. Affected services: Chat API Last error: HTTP 502 Time: 2026-09-02T09:15:53.599Z
Post-mortem
Summary The real-time chat API was unavailable for about 15 minutes on 2026-09-02 (09:05-09:20 UTC). Requests to the chat API returned HTTP 502 because the queue processor worker could not start. The landing page stayed reachable apart from a single failed probe during the same window. Root cause HansaChat started as a startup, and the initial credentials-injection implementation fetched credentials from the upstream API on every request, without any caching. During an unusually intense development day more than 1,000 items were requested in a short window, which exhausted the upstream API's rate limit. Without credentials available the queue processor worker could not start, which took the real-time chat API down with it. Impact Roughly 15 minutes of real-time chat API downtime (09:05-09:20 UTC); queued message processing was stalled for the same window. The landing page was not materially affected. Resolution Service recovered once the upstream rate limit window reset (09:20 UTC). Credentials injection now uses an in-cluster cache, so a temporary upstream rate limit can no longer prevent worker startup.
-
Resolved Website Aug 14, 2026, 18:45 UTC · 9m 45s
HansaChat Status Alert Landing Page has been DOWN for 4 consecutive checks. Affected services: Landing Page Last error: The operation was aborted due to timeout Time: 2026-08-14T18:45:41.129Z
Post-mortem
Summary The landing page was unavailable for about 20 minutes on 2026-08-14 (18:35-18:55 UTC). Chat services recorded no downtime during the incident. Root cause The underlying Kubernetes node failed and its pods were rescheduled. Traefik kept routing correctly to the old pods, which were still serving while being drained. After the deployment of the new landing version, Traefik could not find the new pods' IP addresses, so landing traffic was sent to endpoints that no longer existed. Impact Landing page downtime of roughly 20 minutes. No chat downtime was recorded.
Independent monitor
Built to keep recording when HansaChat itself is down.
This status page is hosted together with the product. The measurements come from a separate worker on Cloudflare that is independent of HansaChat's DNS, hosting region, and infrastructure — if hansa.chat is ever unreachable, the monitor keeps checking and its own page keeps answering.