# Workflows recognize app outages, whatever the app says

> A maintenance page or an error page from any connected app now reads as the app being down, so runs, apps, and triggers wait it out instead of failing.

Oct 21, 2026. Topics: Workflows, Integrations. https://www.generalinput.com/changelog/2026-10-21-outages-recognized-in-any-wording

Every app says it is down in its own words: a maintenance page where its data should be, a note that it is temporarily unavailable, an error tucked inside a normal-looking reply. Until now, a run that met one of those could fail, count against your workflow, and turn it off, even though nothing on your side was broken. Workflows now recognize an outage however the app words it, and wait it out the way they already do when an app stops answering, as described in [how workflows wait out outages](/changelog/2026-10-18-workflows-wait-out-app-outages).

### How it works

- **Any wording.** A clear status code settles it. Anything else is read by a model trained for this one decision, and only a confident read counts as an outage.
- **Runs already under way.** A scheduled run that hits an outage partway through is skipped, and the next one runs as usual. A run started by a new record or a webhook waits up to three days, then runs again from the start once the app answers.
- **The right connection hears about it.** A failed run, an app, or an agent marks the connection it was using as not responding. Its owner is told once after an hour and again when the app is back.
- **Recovery is noticed on its own.** While a connection is down we check it again every few minutes, backing off to every half hour.
- **Connections keep what they knew.** If an app is down while we refresh what a connection can see, we keep the last good copy.

### Also shipped

- Connecting an app while it is down says so, instead of showing the app's error page.