Microsoft Graph subscriptions are sometimes lost silently

Question

Microsoft Graph subscriptions are sometimes lost silently

Faisal Maulana 0

We use Microsoft Graph change notifications with resource data for Outlook mailbox, contacts, and calendar synchronization.

The synced account sometimes lose synchronization. We are investigating whether a reauthorizationRequired lifecycle notification can be delayed or missed before the subscription becomes inactive.

Subscriptions are created with a 3 days lifetime:

var expirationDateTime = DateTime.Now.AddDays(3);

var subscription = new Subscription
{
    ChangeType = changeType,
    NotificationUrl = "https://<domain>/v1/webhook/{resource}",
    LifecycleNotificationUrl = "https://<domain>/v1/webhook/lifecycle",
    ExpirationDateTime = expirationDateTime,
    ApplicationId = "<application-id>",
    CreatorId = "<creator-id>",
    EncryptionCertificate = "<certificate>",
    EncryptionCertificateId = "<certificate-id>",
    ClientState = "<client-state>",
    IncludeResourceData = true,
    Resource = resourcePath
};

var subscriptionResponse =
    await graphClient.Subscriptions.PostAsync(subscription);

We store the returned subscription ID and expiration time in our database.

Current lifecycle event handling

switch (notification.LifecycleEvent)
{
    case LifecycleEventType.ReauthorizationRequired:
        await RenewSubscription(subscriptionId);
        break;

    case LifecycleEventType.SubscriptionRemoved:
        await RecreateSubscription(subscriptionId);
        break;

    case LifecycleEventType.Missed:
        logger.LogWarning(
            "Missed notifications detected for subscription {SubscriptionId}",
            subscriptionId
        );
        break;
}

Intermittently, the sequence appears to be:

The subscription is created successfully.
Resource change notifications are received normally.
Change notifications later stop arriving.
The stored subscription expiration passes.

We would like to guarantee that:

Subscriptions are renewed before expiration.
A lost lifecycle event does not permanently stop synchronization.
Authentication failures are detected promptly so the user can reauthenticate.

Additional Questions

Can webhook-delivery throttling delay or permanently drop a reauthorizationRequired lifecycle notification, or does throttling only apply to resource change notifications?
If delivery of reauthorizationRequired fails, how long does Microsoft Graph retry it?
Can a later missed lifecycle event indicate that a previous reauthorizationRequired lifecycle event was not delivered?
Is the recommended resilient design to renew subscriptions proactively using a scheduled process, independently of lifecycle notifications, or every missed event to renew the subscription?

0 comments

1 answer

Your answer

Answer 1

A resilient design should not rely only on lifecycle notifications.

Supported facts from Microsoft Graph documentation:

reauthorizationRequired is sent when the access token is about to expire, when the subscription is about to expire, or when an administrator revoked the app’s permissions to read a resource.
Microsoft Graph sends that authorization challenge to the lifecycleNotificationUrl.
Change notifications can continue for a while after the challenge is sent, but eventually delivery pauses until the subscription is reauthorized or recreated.
Any resource changes that occur while delivery is paused and before the app successfully creates the subscription again are lost from webhook delivery and must be recovered separately, for example by using delta query.
reauthorizationRequired is supported for all resources.
missed means some change notifications were not delivered, for example because of throttling. The documented response is to acknowledge the event, validate it, and perform a full data resync of the resource, for example with delta query.
subscriptionRemoved means the subscription was removed and must be recreated.

For the design goals listed:

Renew subscriptions before expiration
Use a scheduled renewal process based on the stored expirationDateTime, instead of waiting only for reauthorizationRequired. The documentation explicitly says to extend a subscription before it expires.
Prevent permanent sync loss when a lifecycle event is lost
Treat lifecycle notifications as recovery signals, not the only control plane. If notifications stop or a subscription expires or is removed, recreate or renew the subscription and resync the resource state with delta query to recover missed changes.
Detect authentication failures promptly
reauthorizationRequired is the documented signal for token-expiry, subscription-expiry, and permission-revocation conditions. subscriptionRemoved can also occur when access conditions change and the app may need a new access token before it can create a new subscription.

Answers to the specific questions:

The provided documentation does not state whether webhook throttling applies to reauthorizationRequired lifecycle notifications specifically, or only to resource change notifications.
The provided documentation does not state how long Microsoft Graph retries delivery of a failed reauthorizationRequired lifecycle notification.
A missed lifecycle event means some change notifications were not delivered. The documentation does not state that a later missed event specifically indicates an earlier reauthorizationRequired notification was not delivered.
The documented resilient pattern is to renew subscriptions proactively before expiration and also handle lifecycle notifications. For missed, the documented action is full resync, not subscription renewal by itself. For reauthorizationRequired, acknowledge, validate, ensure a valid access token, and then either call POST /subscriptions/{id}/reauthorize or PATCH /subscriptions/{id}. If reauthorizing and renewing together, use a single PATCH /subscriptions/{id} with an updated expirationDateTime. Do not send POST /subscriptions/{id}/reauthorize and PATCH /subscriptions/{id} for the same subscription within a 10-minute window.

A practical pattern for this scenario is:

Keep the stored subscription ID and expirationDateTime.
Run scheduled renewal before expiration.
Handle reauthorizationRequired immediately and resume the flow by reauthorizing or patching the subscription.
Handle subscriptionRemoved by creating a new subscription.
Handle missed by running a full resync or delta-based catch-up.
If notification delivery pauses or the subscription lapses, assume webhook gaps occurred and recover state from the resource directly.

References: