Failure alerts

What you get

• Alerts by email, Slack or your own webhook
• Each kind of alert sent where you choose
• Each person chooses which emails they get
• A deploy that fails in the app's own code
• A workflow or job that fails three times in a row
• A function paused for looping or flooding
• An app stopped for running out of memory
• A webhook that failed after every retry

How it works

Whisk sends a short alert, with a link to the page that explains it, for problems that need a person. These include a deploy that fails in the app's own code, a workflow that fails three times in a row and an app stopped for running out of memory. They also cover a webhook that failed after every retry and an upload quarantined by the virus scan.

Alerts go by email to the people concerned, such as the owners or the app's developers. They can also go to a Slack channel or any HTTPS address you set. An owner chooses which kinds go to which channel, and each person can turn off emails they do not need.

When a deploy fails, the previous version stays live through health-checked deployments. A problem on Whisk's side is handled by Whisk and sends you nothing. The detail behind an alert is in log search and the app's run history. Allowance warnings, approval requests and payment problems arrive the same way as alerts.

Example

A fastener wholesaler sends its alerts to a systems channel in Slack. When a supplier's price feed webhook keeps failing overnight, the alert is in the channel by morning. It links to the delivery, ready to replay once the supplier is back.

For your coding agent

whisk runs list --status parked
whisk runs show <run id>
whisk runs replay <run id>

whisk apps info shows an app's memory against its limit. Alert channels are an owner's setting in the dashboard, and every command is in the CLI reference.