All systems operational

How we keep BuildAPI running

What we watch, what it showed this quarter, and what we do when something goes wrong.

Live status

This quarter so far

100%of 40 outside checks passed
0incidents posted
—typical time to resolve
Website 100%typically 142 ms
API 100%typically 134 ms
Sign-in & dashboard 100%typically 127 ms

The same figures as the status page and the printable quarterly uptime report.

What we watch

Outside checks, twice an hour

From outside our servers, every public page and API entry point is loaded and must answer without an error. Each check records the website, the API and sign-in separately, with how long they took; two slow checks in a row alert us even when nothing is down.

Every error the site logs

Errors are grouped by kind and emailed to us as a digest, not one message per error. When we mark one fixed and it comes back, the next alert says it is back.

A verified backup every night

The database is copied nightly and each copy is checked where it lies — it opens, it finished, every table is in it. The admin console turns red if a day passes without one.

Every release, tested first

Nothing ships until the full automated test suite passes. Each deploy then checks that every table and column the code expects exists, and loads the live site to make sure it answers.

When something goes wrong

  1. 1
    We post it

    An incident goes on the status page with what you are seeing and which services it affects, then each step: identified, monitoring, resolved.

  2. 2
    We tell you

    Subscribers get one email when it opens and one when it is resolved — only for the services they chose, in English or French — and notice before planned maintenance.

  3. 3
    We write it up

    After a major incident we publish what happened and what we changed, under the incident, in the feed and the API.

Follow along