Azure Functions error handling

Handling errors in Azure Functions is important to avoid lost data, missed events, and to monitor the health of your application.

This article describes general strategies for error handling along with links to binding-specific errors.

Handling errors

Errors raised in an Azure Functions can come from any of the following origins:

  • Use of built-in Azure Functions triggers and bindings
  • Calls to APIs of underlying Azure services
  • Calls to REST endpoints
  • Calls to client libraries, packages, or third-party APIs

Following solid error handling practices is important to avoid loss of data or missed messages. Recommended error handling practices include the following actions:

Use structured error handling

Capturing and publishing errors is critical to monitoring the health of your application. The top-most level of any function code should include a try/catch block. In the catch block, you can capture and publish errors.

Retry support

The following triggers have built-in retry support:

By default, these triggers retry requests up to five times. After the fifth retry, both the Azure Queue storage and Azure Service Bus triggers write a message to a poison queue.

You need to manually implement retry policies for any other triggers or bindings types. Manual implementations may include writing error information to a poison message queue. By writing to a poison queue, you have the opportunity to retry operations at a later time. This approach is the same one used by the Blob storage trigger.

Binding error codes

When integrating with Azure services, errors may originate from the APIs of the underlying services. Information relating to binding-specific errors is available in the Exceptions and return codes section of the following articles: