Database service disruption (Database)

On September 23, 2026 at approximately 08:02 UTC, StatusPage.me experienced a short production service disruption affecting database-dependent requests.

During the incident, some requests timed out or returned errors while other requests continued to complete successfully. Service recovered after approximately five minutes.

Our investigation indicates that the database was affected by a broader host-level scheduling stall rather than by sustained PostgreSQL overload or resource exhaustion.

For approximately five minutes, some customers experienced intermittent request failures and timeouts across parts of StatusPage.me that depend on the production database.

The disruption was not continuous for every request during the entire incident window, and some requests continued to complete successfully.

We found no evidence of data loss, database corruption, or loss of persisted customer data.

The most likely cause was a host-level scheduling stall affecting multiple unrelated processes on the production virtual machine, including PostgreSQL and application workers.

During our investigation, kernel diagnostics showed CPU soft-lockup / RCU-related symptoms, while multiple unrelated processes temporarily stopped making progress at the same time.

We did not observe sustained CPU, memory, disk I/O, swap, or PostgreSQL pressure that would explain the behavior as a normal application or database overload condition.

Our infrastructure provider subsequently moved the virtual machine to another physical host. We have not observed the same stall pattern since.

Because we do not have access to hypervisor-level telemetry, we cannot conclusively identify the exact underlying physical-host failure mode.

At 13:04 UTC (15:04 CEST), our infrastructure provider completed a live migration of the affected production virtual machine to another physical host without requiring a guest reboot.

Following the move, we verified normal application, PostgreSQL, CPU, memory, and I/O behavior and have not observed a recurrence of the same host-level stall pattern.

We are also continuing our previously planned migration of primary production infrastructure from Munich to Nuremberg. This migration had already been announced to customers almost a month before this incident as part of our normal subprocessor-change process.

The September 22–23 host stalls did not cause that migration decision, but they reinforced our decision to complete it and reduce reliance on the affected Munich host for primary production workloads.

We are also improving host-level monitoring and alerting, and continuing work to distinguish confirmed service downtime from isolated regional failures or gaps in monitoring data.

• [08:02 UTC] Automated monitoring detected a production database service disruption.
• [08:02–08:07 UTC] Some database-dependent requests timed out or failed while others continued to complete normally.
• [08:07 UTC] Service recovered and request handling returned to normal.
• [Following recovery] We reviewed PostgreSQL activity, application workloads, connection behavior, memory, swap, disk I/O, and kernel diagnostics.
• [Following investigation] Evidence pointed to a broader host-level scheduling stall rather than sustained database or application overload.
• [13:04 UTC] Our infrastructure provider completed a live migration of the production virtual machine to another physical host without rebooting the guest.
• [After migration] No recurrence of the same host-level stall pattern has been observed.