Status

What we actually measured, against the targets in the uptime SLA. Probed every 5 minutes.

Measurement has not started yet

Month by month

Uptime is measured against the probes that were expected in the month, not against the ones that arrived. A probe that never ran counts as downtime — which is the only way a page like this can report an outage that took the reporter down with it.

MonthDatabaseApplicationAgainst 99.5%
September 2026not measurednot measured
August 2026not measurednot measured
July 2026not measurednot measured

Errors in the last 24 hours

None recorded. Every error the app or a storefront throws is counted here, and the people who run BaseBlock are paged when a new one appears.

What is being measured against

The column above judges every month against 99.5%, the Starter and Business target. Growth and Enterprise are held to more, so a month marked “met” there may still owe a credit on those plans — the SLA has the schedule, and you do not have to produce any of this to claim one.

This is evidence, not proof

The probe is triggered from outside our own infrastructure, so an outage here does not silence the thing measuring it — the request simply fails, and the gap it leaves is counted as downtime. What the probe checks is a real query against a real table and a real page fetched over the internet, which is most of what actually breaks.

It is still our data, though: we write the rows and we publish this page, and we would not accept a supplier's word for their own uptime either. A third-party monitor with its own public history is what settles a disagreement, and we do not have one yet. Until we do: if your figure disagrees with this page, yours is the one that starts the conversation, and a credit claim never requires you to prove anything.

Nothing on this page is a marketing number. It is generated from the rows the probe wrote, and when a month is bad it will say so here before anybody asks.