Share via

Autoupdate on SHIR seems to have re-nabled and forced a restart of the SHIR service

Marsden, Padraic 0 Reputation points
2026-05-21T13:05:18.35+00:00

On April 27th we had an issue with batch jobs that caused delays on key business process, which drew quite a bit of attention.

After some initial investigation it was found that the overnight jobs failed because the SHIR they were running on had the SHIR status as "Upgrading" which restarted the service and killed off the jobs.

We previously set the auto-update setting to disabled to prevent such an occurance, however it seems to have reenabled itself.

Would it be possible to investigate how auto-update was reenabled so we can prevent this in the future.

Thanks,

Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Manoj Kumar Boyini 16,725 Reputation points Microsoft External Staff Moderator
    2026-06-10T18:12:00.2366667+00:00

    Hi @Marsden, Padraic

    We completed the investigation regarding the unexpected Self-Hosted Integration Runtime (ILIM-SHIR) upgrade that occurred on April 27, 2026 and impacted the overnight batch jobs.

    Findings

    During our troubleshooting session, we reviewed the Azure Activity Logs for the Data Factory and identified multiple "Create or Update Integration Runtime" operations that occurred around the same timeframe as the SHIR upgrade.

    The Activity Logs provided visibility into:

    • The exact time when the Integration Runtime configuration was updated.
    • The identity that initiated the update operation.
    • The correlation between the configuration update and the subsequent SHIR upgrade event.

    Based on the evidence available in the Activity Logs, the SHIR upgrade was triggered as part of an Integration Runtime update operation.

    Guidance

    • Validated the relevant Activity Log entries and correlated them with the incident timeline.
    • Reviewed how to identify the initiating identity responsible for Integration Runtime update operations.
    • Discussed how Activity Logs can be used for future monitoring, auditing, and change tracking of Integration Runtime configuration changes.

    As Azure Activity Logs retain the audit trail for management operations, they are the recommended source for determining when configuration changes occurred and which identity initiated them.

    Please let us know if you have any additional questions or require further assistance.

    Was this answer helpful?

    0 comments
  2. Yousif Suliman Sayed Suliman 5 Reputation points
    2026-05-21T13:08:57.2133333+00:00

    Here’s a clearer and more formal version of your message that you can send:

    Subject: Investigation Request – SHIR Auto-Update Re-enabled

    Hi Team,

    On April 27th, we experienced an issue with batch jobs that resulted in delays across key business processes, which understandably caused significant impact.

    Following initial investigation, it was identified that the overnight jobs failed because the SHIR instance they were running on entered an “Upgrading” state, which restarted the service and subsequently terminated the running jobs.

    We had previously disabled the auto-update setting specifically to prevent this type of disruption. However, it appears that the setting has been re-enabled unexpectedly.

    Could you please investigate how and why the auto-update setting was re-enabled, so we can ensure this does not happen again in the future?

    Thanks in advance for your support.

    Kind regards, [Your Name]

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.