Incident History

When RecordKeeper has broken

What it meant for your records, and what changed so it doesn't happen again. Every incident says plainly whether records were lost or exposed.

resolvedThe app loaded but couldn't reach any of your records

August 15, 2026

What you'd have seen
The app opened and then hung — screens sat loading and nothing appeared. For part of the day it returned no response at all rather than an error, which is why it looked frozen rather than broken.
What caused it
Two things at once. Our database provider stopped accepting connections because we'd used up the month's data allowance — the app had been re-fetching everything on screen every 30 seconds, which burned through it far faster than it should have. On top of that, the app's server was written so it couldn't finish starting until the database answered, so instead of staying up and reporting an error it stopped responding entirely.
Your records
No records were lost, changed, or seen by anyone else. Nothing was written during the outage because nothing could reach the database; everything was still there when it came back.
What we did
We moved to a plan with a hundred times the data allowance, and the two changes that caused the overuse (constant re-fetching, and re-downloading every photo on screens that show them) had already shipped the day before. Separately, the server now starts and answers requests before it contacts the database, so a database problem can no longer take the whole service silently offline.

resolvedRecords were unavailable for part of the day

August 14, 2026

What you'd have seen
Screens that load a profile — which is most of them — showed an error instead of your records. Saving new entries failed while it lasted. It looked like the app was down, and effectively it was.
What caused it
We added two new fields to profiles for the pets feature and released the code without adding those fields to the database. Because a profile is read by nearly every screen, that one mismatch broke far more than the new feature.
Your records
No records were lost, changed, or seen by anyone else. This was a failure to READ the database, not a failure of storage and not a disclosure.
What we did
The database was updated the same day and the app recovered immediately. Two changes stop a repeat: the release process now applies these database updates itself instead of relying on someone remembering, and an automated check refuses to release code that references something the database doesn't have. We also found and closed the same gap for 38 other tables that had never been covered.

resolvedWe came close to running out of database capacity

August 14, 2026

What you'd have seen
None — the app kept working. But we were one step away from our database being suspended, which would have taken it offline entirely, so we're recording it rather than quietly fixing it.
What caused it
The app re-fetched everything on screen every 30 seconds, and screens with photos re-downloaded every image each time. Together those used a month's worth of our data allowance in a fortnight.
Your records
No records were lost or exposed. This was about how much data we moved between our own systems, not about who could see it.
What we did
The app now refreshes when you open or return to a window rather than on a constant timer, and photos load only when shown. Both changes are described in the changelog because they alter how the app behaves, not just how much it costs us.

See the changelog → for ordinary product changes.