Service status

Current status, component by component, and the incident history are at status.boardbutler.com. It is monitored independently of our hosting, which is the only way a status page is worth anything during an outage.

Components monitored: the application, the owner portal, payments, bank feeds, email, print mail, meeting capture, and the public interface.

• Open the live status page

A recovery point objective says how much data a disaster could cost you. A recovery time objective says how long service could be gone. Both are commitments, and a commitment nobody has measured is a number rather than a promise.

Our database platform changed while we were building, and the figures written into our internal specification were derived against the previous vendor. Carrying them across would mean publishing a commitment about a system we had not tested. So we publish neither figure today.

They go up here when a restore drill has been run against the platform the data actually sits on, and this page will state the date of that drill and what it measured.

Each component below is backed by a check that runs against the running system: the database answering and reporting the schema this build expects, the job queue's oldest unclaimed piece of work and how long it has waited, the object store, and each outbound vendor connection. The state you see is the worst answer those checks gave.

When a check cannot run at all, the component is reported as degraded and the reason is published with it, and the service as a whole is reported as degraded too. It is never reported as operational. A page that shows green because nothing checked it is worse than no page, because it is most likely to do that at the moment something is wrong.

• Application
• Owner portal
• Payments
• Bank feeds
• Email
• Print mail
• Meeting capture
• API