Monitoring and incidents

GetFlowing watches your running apps. When something breaks, it opens an incident and shows it in your Inbox.

MonitoringCopy Anchor Link

The Health tab's Traffic and errors section shows your app's CPU and memory use over the last hour, day, week or month. Requests, response times, error rates and uptime are not reported for every app yet. Where they are not, the totals read n/a and the charts stay flat.

The same tab shows your app's security findings. See Security scans.

Uptime checksCopy Anchor Link

GetFlowing checks each live app every few minutes. It loads the app's front page and looks at its recent logs. If the problem lasts, GetFlowing opens an incident and marks the app Degraded. The incident is resolved by itself as soon as the app passes again.

A free app that is asleep because nobody has visited it is not checked, and nor is an app stopped because its plan was not paid.

This is as well as the health check every app answers while it runs. See The health check.

IncidentsCopy Anchor Link

Incidents are listed in the Inbox, under Incidents. GetFlowing opens one when:

• a deploy or a release fails;
• taking an app offline fails;
• an app stops serving correctly, from the uptime checks above.

Each incident has a severity, a status and a Timeline of what happened. An incident on a released app is critical. A new incident is Investigating. It is Resolved when a later deploy succeeds, when the app passes its checks again, when the app is taken offline, or when an owner, admin or member chooses Mark resolved. Viewers can read incidents but not resolve them.

When a deploy fails, GetFlowing also raises a request with its team, which you can follow on the Help page. On the Deploy plan, a failure in your own code is yours or your assistant's to fix, so no request is raised for it. See Get help.

NotificationsCopy Anchor Link

GetFlowing can send deploys, incidents and approvals to your own systems as webhooks. See Webhooks. Incidents are not emailed.