Hosted databases and stores: our outages wait, not fail

When a database or store we host for your workflows had trouble, a filter or run waiting on it could hang for minutes and then fail as if your workflow were broken. You got a failure email, the failure counted toward turning the workflow off, and the event that started the run was lost. Those runs now wait out our failure the way they already wait out an app outage.

How it works

• A database request answers within 30 seconds. If the database does not answer in that time, your code gets a clear error saying so instead of waiting for minutes. A read that hits a brief error is tried again inside those 30 seconds, and a write is never sent twice.
• Our failures stay ours. When we fail a request your run made and the run or its filter then fails within ten minutes, the run is recorded as our failure. You get no failure email, and it never counts toward the failures that turn a workflow off.
• Events are held and run again. A run started by a new record or a webhook is held and tried again from its start, soon at first and then hourly, for up to three days, and only then fails and tells you. A scheduled run skips that tick, and the next tick runs as usual.
• A cut-off filter is judged fairly. A filter that hits its own time limit while a database request is still pending is judged only once that request has had its full time.
• The run says why. The run's history names the request we failed, so the reason stays visible.

This builds on how workflows already wait out connected app outages.