Summary. On Monday 31 August 2026 our Free-tier idle detection hibernated one customer's database while their application was actively using it. The database was unreachable for 6 hours 51 minutes. No data was lost or exposed. The cause was a design error on our side: “idle” was measured by whether anyone had signed into the WattleDB console in seven days, not by whether the database was being used. The fix, which checks live database connections before pausing, was deployed to Sydney and Melbourne the same evening; on 3 September we checked the running Sydney provisioner and confirmed it carries the fix.
The Free tier is outside our Service Level Agreement and no credits apply. We are publishing this because the outage was customer-impacting, because our published description of the behaviour was wrong, and because we had no written rule for declaring incidents at the time. We do now: any unplanned unavailability of a customer database longer than 15 minutes, on any tier, is declared on the status page within two business hours of detection, with a post-mortem within five business days. This entry is late by that rule, and we would rather say so than backdate it.
All times Australia/Sydney.
| Time | Event |
|---|---|
| 2026-08-24 (approx.) | Last time the customer opened this database in the WattleDB console. Their application kept connecting and querying normally throughout the following week. |
| 2026-08-31 15:31 | The scheduled idle check selected the database because its last console activity was more than seven days old, and hibernated it. Scheduled backups were suspended while paused. The customer's application began failing to connect and retried continuously. |
| 15:31 to 22:22 | No alert fired. Nothing on the platform detects that a database it has paused is still being asked for. The outage was noticed by a person, not by monitoring. |
| 22:22 | An operator resumed the database. Service restored. Total unavailability 6 hours 51 minutes. |
| 2026-08-31 evening | Root-cause fix deployed to the Sydney primary and the Melbourne standby. |
| 2026-08-31, late | Three register entries opened for the detection and alerting gaps; internal post-mortem completed the next day. |
| 2026-09-03 | Declared publicly under the new declaration rule. Pricing copy reworded to say how pausing actually works. |
One database on the Free tier, unreachable for its normal read and write operations for 6 hours 51 minutes. The customer's workflow-automation application connected and retried throughout. Because the connection pooler held queries before failing them, each attempt cost the application about two minutes before it errored. Data was intact throughout: the database was hibernated, not damaged, and its backup archive recorded no failures. No other customer was affected.
Free-tier databases auto-pause after seven days idle. The only signal the platform used to decide “idle” was the timestamp of the last action taken through the WattleDB console: opening the database page, using the SQL editor, or an operator action. Customer traffic to the database itself never reaches the part of the platform that makes the pause decision, so it was invisible to it. A database under continuous production load with no console visits was therefore “idle” on schedule.
This gap had existed since the auto-pause feature shipped. It first mattered on 31 August because this was the first Free database to run a real workload for seven days without anyone opening the console.
Our published description made it worse. The pricing page said the Free tier “auto-pauses when idle” without saying what idle meant, and the guide said that connecting to a paused database would resume it. The guide's sentence was false as the platform actually worked, and it described behaviour the customer was entitled to expect. The guide was corrected on 31 August and the pricing page now says how pausing works.
Contractually we were not obliged to. The Free tier carries no uptime commitment and this was an availability incident, not a data breach, so neither the SLA nor the Data Processing Addendum was engaged. We are publishing it anyway, because we did it to the customer, because nothing detected it, and because a platform that asks to be trusted with regulated data should keep a public record of the times it fell short. The internal write-up is longer than this page; if you are a customer and want the detail, ask.
Published 3 September 2026. Related pages: Status · Service Level Agreement · Pricing.