meetergo Platform Unavailability

Between 08:45 UTC and 09:45 UTC on October 31, a targeted application-level Denial of Service (DoS) attack caused widespread database contention, leading to platform-wide unavailability. The attack vector was identified and blocked by our engineering team. Full service was restored by 09:45 UTC, and we have been monitoring system stability since. No customer data was compromised during this event. Timeline of Events (UTC) 10:00 UTC - [Resolved] We have confirmed that all Meetergo services are stable and operating under normal load for a sustained period. This incident is now considered resolved. 09:45 UTC - [Monitoring] The mitigation has been fully deployed, and platform services have been restored. We are observing successful user traffic and normal system metrics. We will continue to monitor closely before resolving this incident. 09:34 UTC - [Update] The backlog of pending bookings has been manually cleared, and all residual blocking database sessions have been terminated. We are now initiating a rolling restart of our application fleet to restore healthy database connections. Platform availability is beginning to recover for all users. 09:22 UTC - [Update] Investigation shows that while the initial attack vector is closed, our system is now heavily loaded attempting to process a large queue of failed booking requests generated during the attack. This is preventing full service recovery and keeping application instances unresponsive. The team is now working to manually clear this backlog from the database. 09:08 UTC - [Update] The specific public meeting type targeted by the attack has been temporarily disabled. This has stopped new malicious requests from creating locks and has led to some improvement, but overall platform performance remains degraded with many instances still unresponsive. 09:01 UTC - [Identified] We have identified the root cause of the issue. A single public meeting page is being targeted by a distributed botnet attack, causing a database bottleneck. We are now working on immediate containment. 08:52 UTC - [Investigating] As part of our investigation into platform-wide latency, we deployed a hotfix to rule out a potential issue with an incoming webhook processor. This did not resolve the issue, and we are continuing to investigate the root cause in the database layer. 08:45 UTC - [Investigating] We began receiving automated alerts for a critical number of unhealthy hosts and a spike in database latency. Our engineering team was engaged, and an incident has been declared. Root Cause The incident was caused by a sophisticated application-level DoS attack, not a volumetric network attack. The attack mechanism can be broken down as follows. - Attack Vector: The threat actor leveraged a botnet of dozens of unique IP addresses to target a single, publicly accessible meeting page. - Mechanism: The attack consisted of a high volume of concurrent booking requests for the exact same timeslot. Each malicious request used unique, fake attendee details but shared an identical digital fingerprint (User Agent), confirming its automated nature. - Cascading Failure: The simultaneous attempts to modify the same record created severe row lock contention in our primary database. This initial contention caused a chain reaction: legitimate queries were blocked, leading to the exhaustion of our application server connection pools. As a result, our compute instances became unresponsive, leading to a total service outage.