Azure Container App Job Event Trigger Stops Working After Suspend/Start Operation

Question

Azure Container App Job Event Trigger Stops Working After Suspend/Start Operation

mallikarjuna avula 20

Service: Azure Container Apps (Jobs)

Severity: Moderate

Issue Summary:

After performing a suspend/start operation we are experiencing an issue with Azure Container App Jobs. The job intermittently fails to respond to event-based triggers. Manual executions continue to work, but automated event-triggered executions may fail or behave inconsistently.

Observed Behavior:

Azure Container App Job initially functions as expected.
Suspend and subsequently start the job.
Event-based triggers no longer execute reliably.
In some cases, events are not processed at all.
Manual job execution continues to work.

Expected:

After a suspend/start operation, the Azure Container App Job should continue responding to event-based triggers without requiring any additional intervention.

Impact:

Workloads relying on automated event processing may stop executing.
Current workaround requires deleting and recreating the job, which is operationally disruptive.

Request:

Provide the current status of the fix and any available ETA.

Known References:

RCA - https://github.com/microsoft/azure-container-apps/issues/1458

Temporary Workaround - https://learn.microsoft.com/en-us/answers/questions/2245402/container-app-job-auto-trigger-suddenly-stopped-wo

0 comments

Answer accepted by question author

Jerald Felix 18,760 Volunteer Moderator

Hello mallikarjuna avula,

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

This is a known platform bug in Azure Container Apps Jobs, not a configuration issue on your side. It has already been reported and is being tracked by the Container Apps engineering team on GitHub.

Root cause

When a Container App Job with event-driven (KEDA) scaling is suspended while messages still exist in the trigger source (Service Bus queue/topic, etc.), the suspended executions interfere with the scaler's binding when the job is resumed. This leaves the job "out of sync" with KEDA, so it stops firing reliably on new events, while manual triggers keep working because those bypass the KEDA scaler entirely. This matches the RCA thread you linked at microsoft/azure-container-apps#1458, where Microsoft engineers (v-vish) confirmed the issue is escalated internally and under investigation, but no fixed release date has been published as of now.

Workarounds available today

Avoid suspending while messages are queued. If possible, drain the source queue/topic to zero before suspending the job. The interference specifically happens when jobs get created and then immediately suspended while messages are still pending.

Explicitly set messageCount on the scale rule. If your scale rule does not set messageCount, it defaults to 5, which combined with a suspend/resume can make the scaling threshold behavior worse or inconsistent. Set it explicitly to 1 if you want one execution per message:

"scale": {
  "rules": [
    {
      "name": "servicebus-rule",
      "custom": {
        "type": "azure-servicebus",
        "metadata": {
          "messageCount": "1"
        }
      }
    }
  ]
}

Delete and recreate the job as the confirmed working workaround, same as documented in the thread you referenced at learn.microsoft.com/en-us/answers/questions/2245402. To reduce the operational disruption this causes, script the recreation with an ARM template or Bicep file so you can redeploy the same job definition quickly rather than reconfiguring manually each time:

az deployment group create --resource-group <your-rg> --template-file containerappjob.bicep --parameters jobName=<your-job-name>

On status and ETA

Since there is no published fix or ETA yet, the most effective steps you can take are:

Add a "👍" reaction on the original post in microsoft/azure-container-apps#1458 to help with prioritization.
Open an Azure Support ticket referencing this GitHub issue and, if relevant, the existing support case number 2512160040008333 already tied to this bug so your impact gets aggregated against the same tracked issue rather than opening a separate investigation thread.

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

Best Regards,

Jerald Felix.

mallikarjuna avula 20 Reputation points

2026-07-02T23:27:47.1666667+00:00

Thank you for the response, Jerald & Pravallika.

1 additional answer

Your answer

mallikarjuna avula 20 Reputation points

2026-07-02T23:27:47.1666667+00:00

Thank you for the response, Jerald & Pravallika.

Answer 1

Hi @mallikarjuna avula ,

Azure Container Apps jobs can be triggered as Manual, Schedule (cron), or Event-driven (Event) jobs. For event-driven jobs, job executions are driven by KEDA scaling events (polling scaling rules evaluate event volume, and then trigger executions).

So, if event-based triggers become unreliable after suspend/start, the most likely area to check is whether the trigger/scaling rule and the job’s event processing pipeline are still behaving normally afterward.

Check job execution history + logs

Look up job execution history
- Use the Azure CLI or Resource Manager to get the job execution history (commands referenced from the “Get execution history” guidance).

Query logs for the affected event-driven job execution attempts

Jobs can be monitored via the logs provider configured for the Container Apps Environment.
Example Log Analytics query (from the docs):


   let job = "<myjob>";

   ContainerAppConsoleLogs_CL

   | where ContainerJobName_s =~ job

   | project TimeGenerated, Log_s, ContainerGroupName_s, EnvironmentName_s

   | order by TimeGenerated asc

This helps confirm whether:

the event-driven trigger actually caused executions to be created, or
executions are being created but failing / not processing events correctly after the suspend/start cycle.

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.