Service Level Agreement

01Uptime commitment

We commit to a Monthly Uptime Percentage of at least 99.5% for each paid, always-on database (Hobby, Launch and Scale tiers) and its auto-generated REST API. 99.5% allows for up to about 3.6 hours of unplanned unavailability in a 30-day month. We often do better than this; the commitment is deliberately set at a level we are confident we can honour on our current single-primary architecture, and we will raise it for qualifying workloads when the high-availability standby (section 3) is live.

Object storage is outside this commitment. Buckets are served from Sydney and are not part of the recovery path in section 3 (see section 6). The commitment above, and the cross-state backups and recovery described in section 3, apply to your PostgreSQL database and its auto-generated REST API.

Object storage is served from Sydney, with a cross-state copy in Melbourne that is running as of 8 September 2026. That copy holds the current version of each object, refreshed periodically. It is a copy we restore from, not a second endpoint you can reach: after a Sydney loss your access key would not exist anywhere else, so files would be safe without being reachable by you until we restored them. It guards against losing Sydney; it does not guard against deleting a file, because a deletion in Sydney is copied across too. Deleted or overwritten files stay recoverable for 30 days on the Sydney volume, and that history exists in Sydney only. Keep your own master copy of anything you cannot re-create. Object storage remains outside this SLA; we intend to bring it in only once the copy has runtime behind it.

Free tier databases are provided as-is, auto-pause when idle, and are not covered by this SLA. Features marked “coming soon” or offered in beta or early access (for example a hosted authentication service, realtime, transactional email and client-side encryption) are not covered until they reach general availability and this SLA is updated to include them.

02How uptime is measured

Monthly Uptime Percentage = (total minutes in the calendar month − Unavailable minutes) ÷ total minutes in the month, expressed as a percentage, in the Australia/Sydney time zone.

Unavailable means your database is unreachable for its normal read and write operations for reasons within our control, evidenced by a support ticket you raise or by our own platform health records. A single brief connection error or retryable timeout is not counted; sustained unavailability is. Availability is measured at the database and API layer, not the performance of your own application code or queries.

03Where your data runs

Every paid database runs on a primary in Sydney (au-syd-1, NEXTDC S1), with automated backups and a continuous change-log streamed to a separate facility in Melbourne (NEXTDC M2) for cross-state disaster recovery. Both sites are on Australian-owned infrastructure, with no foreign parent in our ownership chain, and no one outside WattleDB and our Australian hosting and data-centre providers has access to your databases or your backups.

We are transparent about our recovery model. Today, recovery from a primary-site failure is a restore from the cross-state backups to a healthy node (a recovery-time objective measured in the low hours, with a recovery-point objective of minutes), not an instantaneous automatic failover. We are adding a high-availability standby so that qualifying workloads can fail over automatically; when it is live, the higher-availability commitment for those workloads will be published here and reflected on the status page. We will not claim automatic failover before it exists.

04Service credits

If we miss the commitment in a calendar month, you may claim a service credit as a percentage of that database’s monthly fee, applied to a future invoice:

Service credits, requested as set out in section 7, are your sole and exclusive contractual remedy under this SLA for any failure to meet the uptime commitment. Credits apply to the affected database, are issued as credit against future fees (not a cash refund), are capped at 100% of that database’s fee for the month in question, and cannot be claimed for Free-tier databases.

To the maximum extent permitted by law, and except for liability that cannot be excluded under the Australian Consumer Law, our total aggregate liability arising out of or in connection with our failure to meet the uptime commitment in this SLA is limited to the service credits payable under it, and we are not liable for any indirect, incidental, special or consequential loss, or for loss of profits, revenue, goodwill, or data, however arising. Nothing in this SLA excludes, restricts or modifies any consumer guarantee, right or remedy you have under the Australian Consumer Law that cannot lawfully be excluded; those rights prevail over anything in this document to the contrary. This SLA does not limit our liability in respect of anything it does not commit to: services and features outside its scope (including object storage, Free-tier databases, and features marked “coming soon”) are provided on a commercially reasonable-efforts basis under our Terms of Service. This SLA is offered in good faith and forms part of, and is read together with, our Terms of Service.

05Scheduled maintenance

From time to time we perform planned maintenance. We aim to give at least 48 hours’ notice for any maintenance expected to cause downtime, scheduled where practical for low-traffic hours (Australian evenings and weekends), and posted on the status page. Announced scheduled maintenance does not count as Unavailable time.

06Exclusions

The commitment and credits do not apply to unavailability caused by:

• factors outside our reasonable control, including a failure of the internet, third-party networks, or a force-majeure event (natural disaster, fire, power-grid failure, act of government);
• your own application, code, queries, schema, or misconfiguration, or your exceeding your plan’s resource, connection or storage limits;
• suspension or termination of your account for breach of the Terms or Acceptable Use Policy, or for non-payment;
• announced scheduled maintenance, or emergency maintenance needed to protect security or data integrity;
• unavailability of object storage (storage.wattledb.com.au) itself, which is served from Sydney; the Melbourne copy is a restore path and not a second endpoint. This exclusion does not apply to unavailability of your database or its REST API, which stays covered however it is caused;
• Free-tier databases, beta / early-access / “coming soon” features, and your use of the service in a way we do not support.

07How to claim a credit

Email support@wattledb.com.au within 30 days of the end of the affected month, from your account email, with the database name and the dates and times you observed the unavailability. We will review your claim against our platform health records and any evidence you provide. Where those records are inconclusive, we will resolve the claim in your favour, and where the commitment was missed, apply the credit to your next invoice.

08Changes to this SLA

We may update this SLA as the platform evolves, for example to add a higher availability tier when the high-availability standby is live, or to bring newly general-available features into scope. Material changes will be posted here with a new effective date and version, and where they reduce your rights we will give reasonable advance notice. The version in force is the one published on this page.

Version 1.4 (8 September 2026): records, as section 1 undertook to, that the cross-state copy of object storage buckets in Melbourne is running. It was verified on 8 September 2026 by writing an object in Sydney, running the copy, and matching its SHA-256 on the Melbourne machine. Sections 1 and 6 now describe it, and state plainly what it is not: a copy we restore from rather than an endpoint you can reach, and protection against losing Sydney rather than against deleting a file. Object storage remains outside the uptime commitment and the credits, so no commitment changes and nothing here reduces your rights.

Version 1.3 (3 September 2026): corrects section 1. Version 1.2 described a cross-state copy of object storage buckets as live. That copy was built on 23 August 2026 but had not been switched on when version 1.2 was published, and had still not been switched on when this correction was made. It was switched on and verified on 8 September 2026; see version 1.4 above, which describes what it is and what it is not. Section 1 and section 6 of version 1.3 described object storage as single-copy in Sydney. Object storage was already outside the uptime commitment and the credits, so no commitment changes; the correction is to a description, and we are recording it here rather than editing history. Nothing in this version reduces your rights.

Version 1.2 (23 August 2026, corrected by version 1.3): a cross-state backup copy of object storage buckets in Melbourne is now live and described in section 1. Object storage remains outside the uptime commitment and remains listed in the section 6 exclusions, because a backup is a restore path and not a failover. Nothing in this version reduces your rights.

Version 1.1 (22 August 2026): object storage scoped out of the uptime commitment and added to the exclusions in section 6, and the liability cap in section 4 narrowed to this SLA’s own commitment. The commitment for databases and their REST API is unchanged.

09Contact