Logic apps trigger state reset to 0001-01-01 causing a flood of triggers and runs

Nishi Katiyar 20 Reputation points • Microsoft Employee

We have a logic app that polls ADO pipeline every 5 mins for any runs and if there are new runs matching a certain criterion, it queries more data related to it and sends an email.
The app sent out a flood of emails without any new runs on the ADO pipeline. Upon investigation I see the trigger state was reset to some arbitrary value and there were a flood of triggers and runs. We have the logic app disabled for now to stop the inbox spam. From docs, it looks like resetting the trigger would help.

Environment Details:

  • Logic App Runtime: Consumption plan
  • Trigger: ADO pipeline run completion
  • Polling Frequency: Every 5 minutes
  • Region: West US2
  • Workflow Type: Stateful

Questions:

  1. Is resetting the trigger the correct workaround for this?
  2. What can cause this to happen?
  3. How to ensure this does not happen again?

👁 User's image

  1. Siddhesh Desai 7,480 Reputation points • Microsoft External Staff • Moderator

    Hi

    Thank you for reaching out to Microsoft Q&A.

    This issue occurs because your Logic App is using a polling-based Azure DevOps trigger, which relies on maintaining an internal state (watermark or last processed timestamp). If this state gets reset (for example to 0001-01-01T00:00:00Z, which is the default minimum value), the trigger assumes that no prior runs were processed and starts fetching all historical pipeline runs again. As a result, the Logic App reprocesses old data, causing a flood of triggers and repeated workflow executions even though no new pipeline runs occurred. This behavior is inherent to polling triggers, which depend on stored state to fetch only incremental changes.

    Refer below points to resolve this issue or this is the workaround

    Reset the trigger to reinitialize state

    • Resetting the trigger clears the corrupted or lost watermark and forces the Logic App to start fresh from the current point.
    • After reset, validate by triggering once and confirming that only new pipeline runs are processed.

    Implement idempotency to avoid duplicate processing

    • Store processed identifiers (e.g., pipelineRunId) in a persistent store (Table Storage/Cosmos DB).
    • Before sending email, check if the run is already processed → skip duplicate execution.

    Add time-based filtering as a safety guard

    • Introduce a condition in the workflow to only process recent data:

    expression isn’t fully supported. Syntax highlighting is based on Plain Text.

    @greater(triggerBody()?['createdDate'], addMinutes(utcNow(), -10))
    • This ensures even if the trigger resets, historical runs are ignored.

    Add a hard time-window validation (defensive design)

    • Reject any pipeline runs older than a defined threshold (e.g., 10–30 minutes).
    • Prevents large replay storms in case of trigger state resets.

    Limit trigger concurrency to avoid flood amplification

    • Go to trigger settings → enable Concurrency Control → set limit to 1.
    • Prevents multiple parallel executions during abnormal events.

    Avoid unnecessary redeployment or disable/enable cycles

    • Redeployments or toggling the Logic App can sometimes reset trigger state.
    • Ensure IAC deployments (Terraform/Bicep) do not recreate trigger definitions unnecessarily.

    Monitor and alert for abnormal spikes in runs

    • Use Azure Monitor alerts on run count anomalies.
    • Helps detect such incidents early before email flooding occurs.

    Consider moving to event-based trigger instead of polling

    • Use Azure DevOps webhooks instead of polling triggers.
    • Eliminates dependency on stored state and avoids this class of issues completely
Sign in to comment

Answer accepted by question author

Jerald Felix 13,500 Reputation points • Volunteer Moderator

Hello Nishi Katiyar

Greetings! Thanks for raising this question in Q&A forum.

This is a well-documented and well-understood behaviour in Azure Logic Apps, and you've diagnosed it correctly. The trigger state resetting to 0001-01-01 (the .NET minimum DateTime value) is a known issue that effectively tells the Logic App's polling engine to treat everything from the beginning of time as "new", which causes it to re-process all historical ADO pipeline runs and flood your inbox. Let me answer each of your three questions clearly.

Answer to Question 1 — Is resetting the trigger the correct workaround?

Yes, resetting the trigger is the correct and documented workaround to stop the flood and restore normal behaviour. Here's how to do it properly. First, make sure the Logic App is still disabled (which you've already done good). Then, in the Azure Portal, open your Logic App, go to Overview, and click Reset under the trigger state, or use the Logic Apps REST API to reset the trigger history watermark to a current timestamp. After resetting, re-enable the Logic App. The trigger will now only pick up ADO pipeline runs that complete after the reset timestamp, and will no longer re-process historical runs.

You can also reset via the Azure CLI:

az rest --method delete \
 --url "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Logic/workflows/{logicAppName}/triggers/{triggerName}/histories?api-version=2016-06-01"

Answer to Question 2 — What causes this to happen?

There are a few known causes for the trigger state resetting to 0001-01-01 on a Consumption plan Logic App. The most common ones are a platform-side internal state corruption in the trigger storage (which occasionally happens during Azure infrastructure maintenance or scaling events on the shared Consumption plan), saving or republishing the Logic App workflow definition which can reset the trigger watermark in some scenarios, a transient failure in the trigger's polling metadata storage that causes it to default to the minimum DateTime value on the next poll cycle, and in rarer cases, a connector update for the ADO connector that refreshes the trigger state.

Since you're on a Consumption plan with a stateful workflow, the trigger state is stored in Azure-managed storage, and occasional resets due to infrastructure events are a known limitation of the Consumption tier.

Answer to Question 3 — How to prevent this from happening again?

There are a few defensive measures you can take. First, add a date filter condition inside your Logic App workflow — after the trigger fires, add a condition that checks whether the ADO pipeline run's completion timestamp is within the last 10 or 15 minutes (relative to utcNow()). This acts as a safety net so that even if the trigger state resets, only genuinely recent runs will proceed to send emails, and historical re-fires will be filtered out automatically. This is the most reliable defence against this issue.

Second, consider migrating to Standard plan if this is a production-critical workflow. The Standard plan gives you dedicated compute and more resilient trigger state management compared to the multi-tenant Consumption plan.

Third, set up an Azure Monitor alert on Logic App run count if the number of runs in a 5-minute window exceeds a threshold (say, more than 10 runs), fire an alert to notify you immediately. This won't prevent the flood but will help you catch it much faster next time.

Fourth, you can add a concurrency limit on the trigger (set maximum concurrent runs to 1 or a small number) to limit the blast radius if this happens again.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

0 comments No comments
Sign in to comment

0 additional answers

Sign in to answer

Your answer