API status
We probe five real /api/v1 calls from outside our own network every 15 minutes, with a real API key. This page publishes what those probes saw, including the times they failed.
Incidents
- API returned 503 for about 15 minutesMajorresolvedSep 27, 2026, 13:15 UTC to Sep 27, 2026, 13:30 UTC — up to 15 minutes
Every API request was answered with HTTP 503 for one 15-minute check interval. Requests were rejected quickly (3.6-7.5 seconds) with a Retry-After header rather than left to hang, and the next check was clean.
Cause: Our API-key lookup could not reach the database layer, so the service returned 503 auth_unavailable rather than risk telling a valid key it was invalid. The database itself was healthy throughout -- a separate direct-connection probe succeeded during the same window.
What a caller could do: Retrying after the advertised interval succeeded.
- API requests timed out for up to 15 minutesMajorresolvedSep 27, 2026, 05:47 UTC to Sep 27, 2026, 06:00 UTC — up to 15 minutes
All five monitored request shapes received no response within 25 seconds. Our own direct database probe failed in the same window.
Cause: The managed Postgres instance and its connection pooler were both unreachable. Server logs recorded the database refusing connections, consistent with a platform-side restart rather than load.
What a caller could do: Requests issued after the window succeeded. This class of failure is why the API now answers 503 with Retry-After instead of hanging where it can.
- API requests timed out for up to 15 minutesMajorresolvedSep 25, 2026, 09:47 UTC to Sep 25, 2026, 10:00 UTC — up to 15 minutes
All five monitored request shapes received no response within 25 seconds. Our own direct database probe failed in the same window.
Cause: Same shape as the 2026-09-27 05:47 event: the managed Postgres instance and its pooler were unreachable.
What a caller could do: Requests issued after the window succeeded.
- Monitoring could not resolve our own hostnameInforesolvedSep 23, 2026, 19:15 UTC to Sep 23, 2026, 19:30 UTC — up to 15 minutes
Five monitored shapes failed instantly (0 ms) with a DNS resolution error from our monitoring host.
Cause: A name-resolution failure on the machine running the checks. We cannot establish from this evidence whether customers were affected, and we are not going to claim they were not.
What a caller could do: None known.
- Searches returned errors instead of resultsMajorresolvedSep 8, 2026, 18:30 UTC to Sep 8, 2026, 18:45 UTC — up to 15 minutes
Contractor and address searches returned HTTP 500 after 8-17 seconds.
Cause: Database statement timeouts under concurrent bulk-write load. The queries were not slow in themselves; the disk was busy. These were reported as a server fault, which was wrong -- they were a capacity condition.
What a caller could do: Fixed on 2026-09-27: this class now returns 503 search_timeout with a Retry-After header and a hint about narrowing the search, instead of a 500.
- API returned errors for up to 15 minutesMajorresolvedSep 7, 2026, 09:15 UTC to Sep 7, 2026, 09:30 UTC — up to 15 minutes
All five monitored shapes returned HTTP 500 after 7-12 seconds.
Cause: The database API layer could not load its schema cache and reported that it could not query the database.
What a caller could do: Fixed on 2026-09-27: this class now returns 503 upstream_unavailable with a Retry-After header instead of a 500.
How this is measured
Synthetic probes of five customer-facing /api/v1 shapes, every 15 minutes, from outside our network, using a real API key.
The unit is the individual check, not the round of checks. A round where one of five calls failed counts as one failure out of five, because that is what it was for whoever made that call.
Our own monitoring database probe (rpc-proconfig) is excluded: it is not a shape any customer calls, and counting it would let a healthy API read as an outage and an outage read as healthy.
Calls probed: contractor-lookup, permits-by-address, permits-by-contractor, permits-by-name, permits-by-name-common. Records start Sep 6, 2026, 19:45 UTC (43.7 days).
These numbers are published on a delay, not live. This page was generated Oct 20, 2026, 12:05 UTC (just now), and the newest observation in it is from Oct 20, 2026, 12:00 UTC. For live behavior, call the endpoint you use and read the status code: a 503 with a Retry-After header means the condition is temporary and the same request usually succeeds, while a 500 means we have a bug worth reporting. The same payload is available as JSON at /api/v1/status, no key required.