Design for the finite retry window of managed-application notifications

Source facts

The managed-application notification service expects HTTP 200 OK. It retries HTTP 429, errors of 500 or above, and temporary endpoint unreachability. If the endpoint remains unavailable for ten hours, the notification is dropped and retrying ends.

Azure appends /resource to the configured notification endpoint URI. The definition accepts only one notification endpoint. The source’s authentication guidance also calls for checking the expected signature parameter and comparing the notified provisioning state with the application’s current state. Microsoft Learn.

Applicability

Identify the publisher endpoint, authentication mechanism and business action triggered by each lifecycle event. This brief does not assume every failed HTTP response is retried.

DSE recommendation

DSE recommends making callback availability and missed-event reconciliation explicit responsibilities. Test the appended route, not just the website root. Define how an outage longer than the delivery window will be reconciled against actual application instances before replaying business actions. Protect signature values as credentials and keep them out of routine logs or tickets.

Verification

In an approved test, observe successful delivery and a controlled retryable failure at the intended route. Verify authentication and compare the event with current application state before accepting the action. Rehearse reconciliation using a deliberately omitted test event without waiting for a production outage. Preserve response codes, event identity and disposition while excluding secret query values.

Official references

Microsoft Learn: Azure managed applications with notifications. Source retrieved September 9, 2026.