It's not that they were preventing the local database unlock, they were preventing acquiring a credential to the server in order to sync any changes to/from the central store. As mentioned in a sibling comment, it's was also specifically the login endpoints that were labeled as bogus, so my suspicion is that any credential acquired before the incident may have continued to work

My 1Password for Linux was emitting `Some(Status=500)` on the console, so I'd presume they botched a rollout and then just rolled it back. Unknown why it took an hour, but maybe it's the old adage about 59 minutes to find the bolt, one minute to replace it

I don't know if 1Password/AgileBits publishes postmortems nor if they'd be of sufficient detail even if they did

> Powered by Atlassian Statuspage

seems to me a plausible reason why it might be silly

An alternative theory is that maybe 1Password defines unavailability in some nuanced way given their local-cache client model as well as this allegedly only affecting sign-in, with presumably anyone with a live session at 11:35 being able to use the rest of their API

Also, https://status.1password.com/incidents/3cqc0kx5qdzz is the actual thing, since clicking "history" takes some horrific amount of time to load, as a nod to the aforementioned "Atlassian Excellence in Execution"