Context
An event-driven Container Apps job starts finite executions in response to a scaling signal. A scaler noticing queue demand, an execution being created and a business operation completing are separate events. Confusing them can leave messages unprocessed or acknowledged before their work is safely committed.
Prerequisites are the job definition, trigger entity, execution history and application logs. Identify the queue's visibility or lock behavior and the job's acknowledgement code. Use an approved test message with a unique business identifier and a harmless or reversible effect.
1. Verify that demand creates executions
Read the trigger type, scaler metadata, authentication and execution limits. Confirm that the queue or subscription matches the producer's destination. Compare observed backlog with polling activity and execution creation during the same interval.
If no execution starts, investigate scaler authentication and network access before changing container code. If executions exist but replicas never start, inspect image pulls and resource configuration. Preserve execution names so logs can be associated with the right attempts rather than only the job's shared name.
2. Read completion settings together
Inspect replica timeout, retry limit, parallelism and required replica completion count. Parallelism controls replicas within an execution; maximum executions is a different limit. Multiple parallel replicas can compete for work or multiply downstream load if the application's work selection does not fit that design.
A retry limit does not guarantee all attempts can run before the overall replica timeout boundary. Compare the configured values with real startup and processing durations. Inspect exit codes and termination details. A process exiting successfully proves only what its own success contract checks.
3. Align acknowledgement with durable work
Review where the worker receives, processes and deletes or settles a message. Acknowledge only after the required business effect is durably recorded. If a worker crashes afterward but before acknowledgement, it may receive the message again. Protect downstream effects with an idempotency record keyed by the business operation.
Check visibility or lock renewal for long-running processing. Ensure the message does not become available to another execution while the first is still doing unprotected work. Bound retries and provide a deliberate route for permanently invalid inputs. Keep replay decisions separate from automatic execution retry.
Diagnostic checkpoints
| Observation | Suspected stage | Next evidence |
|---|---|---|
| Backlog rises, no executions | Trigger polling | Scaler logs and credentials |
| Execution exists, image never starts | Replica startup | Pull and resource errors |
| Success status, missing business result | Weak exit contract | Commit and acknowledgement logs |
| Duplicate effects after interruption | Replay safety | Idempotency ledger |
Illustrative scenario
A hypothetical conversion job deletes a queue message immediately after receiving it, then uploads the converted file. An interruption between those operations loses the work despite an earlier queue decrease. The review moves acknowledgement behind durable output and adds duplicate protection. This fictional example makes no claim about a customer incident.
Verification and jobs SOP
Test normal completion and an approved interruption around the commit boundary. Verify exactly which business identifier completed and whether a redelivery produces another effect. A drained queue is not sufficient evidence of correct processing.
Maintain timeout, concurrency, acknowledgement and invalid-input rules in the SOP. Export durable execution evidence through the environment's log provider because portal execution history is limited. Monitor time to completion, failed replicas and reconciliation gaps alongside queue depth. Revalidate after changing job parallelism or the average work duration.
Explore Clouvenix containers kubernetes for implementation and operational handover.