Why WattleDBFeaturesPricingvs SupabaseIndustriesBlogFAQContactAddress API (WattleAddr) Sign inStart free
WattleDB  /  System Status

System Status

Component status & declared incidents · days in service from launch

All components in service

One incident on record. 31 August 2026: one Free-tier database was hibernated for 6h51m by our idle detection. Resolved the same day; declared here on 3 September 2026. Read the post-mortem.
Console & REST API
app + auto-generated PostgREST APIs
In service
Database — Sydney primary
au-syd-1 · NEXTDC S1, Sydney NSW
In service
Backups & DR — Melbourne
NEXTDC M2, Melbourne VIC · cross-state backups + PITR
In service
Object storage
S3-compatible · served from Sydney · single copy today: a cross-state copy is built and not yet switched on · not covered by the SLA
In service
Warm standby — Melbourne
NEXTDC M2 · replicas are built; we are rebuilding the monitoring that verifies they are current · promotion is manual, not automatic failover · not covered by the SLA
Partial

“In service” means the component is deployed and we have not declared an incident against it. These rows are maintained by our operators when we declare or resolve an incident; they are not a continuous automated probe, and this page does not poll anything when you load it.

Days in service

Each bar is one day since launch. This strip shows days in service, not measured availability — we do not yet run external uptime monitoring, so a coloured bar means “WattleDB was running that day and no incident was declared”, not a measured percentage. We publish only what we have actually run, so the record starts at launch — we don't backfill dates from before WattleDB existed. Grey means “before launch, no service to measure”.

90 days agotoday
Since launch
—
days in service (from 12 Jul 2026)
Incidents
1
declared as customer-impacting, since launch
Uptime commitment
99.5%
per the SLA, paid tiers
Incident history
31 August 2026, 15:31 to 22:22 AEST (6h51m). One Free-tier database was hibernated by our idle detection while it was in active use, because “idle” was measured by console sign-ins rather than by database connections. No data was lost. The fix, which checks live connections before pausing, was deployed the same day. The Free tier is outside the SLA, but the outage was customer-impacting and our published description of the behaviour was wrong, so it is declared here. We did not have a written rule for declaring incidents at the time; we do now, and this entry was added on 3 September 2026 under it. Full post-mortem.

Any unplanned unavailability of a customer database or its REST API longer than 15 minutes, on any tier, is declared here within two business hours of detection, with a plain-English post-mortem within five business days. For the availability commitment and service credits, see the Service Level Agreement.

We do not yet publish continuously measured uptime. This page records the incidents we have declared and the components we have deployed; the strip above shows days in service, not measured availability. We are standing up external uptime monitoring, and when it is running we will publish formal monthly uptime percentages here and say plainly which month they start from. Until then, treat the 99.5% figure above as the commitment we make in the SLA, not as a measurement. Questions about availability for a specific workload? Talk to us.