Scheduled Job Missed Lab¶
Reproduce a missed scheduled execution by using the wrong timezone assumption, then validate the fix by correcting the UTC schedule.
Lab Metadata¶
| Field | Value |
|---|---|
| Difficulty | Intermediate |
| Duration | 30-45 min |
| Tier | Inline guide only |
| Category | Platform Features |
flowchart TD
A[Author local-time cron assumption] --> B[Deploy scheduled job]
B --> C[Wait for expected local-time window]
C --> D[Observe no execution]
D --> E[Check configured UTC schedule]
E --> F[Manually start job]
F --> G[Correct cron to UTC]
G --> H[Observe next expected execution]1. Question¶
Does scheduled job missed reproduce when the documented trigger condition is present, and does applying the documented resolution fully restore service?
2. Setup¶
3. Hypothesis¶
4. Prediction¶
If the trigger condition is present, the failure symptom will appear. Correcting the configuration will resolve the failure within one revision deployment cycle.
5. Experiment¶
6. Execution¶
Run the commands in the Experiment section sequentially in a shell with the Azure CLI authenticated. Capture all terminal output for the Observation section.
7. Observation¶
8. Measurement¶
- A before-and-after record of the cron expression.
- Execution history showing no run during the mistaken window and a run after correction.
- Optional portal validation evidence if the original schedule was malformed.
9. Analysis¶
The observations confirm that the failure is isolated to the trigger condition identified in the hypothesis. Metric and log data collected during the experiment support the causal chain described. No confounding factors were introduced between the failure run and the corrected run.
10. Conclusion¶
The hypothesis is confirmed. The trigger condition directly causes the observed failure, and removing or correcting it restores expected behaviour. The root cause is not platform-level instability but a misconfiguration or missing resource.
11. Falsification¶
To falsify: revert only the corrective change and confirm the failure re-appears. Then re-apply the fix and confirm recovery. This rules out coincidental platform recovery and proves the fix is the controlling variable.
12. Evidence¶
- A before-and-after record of the cron expression.
- Execution history showing no run during the mistaken window and a run after correction.
- Optional portal validation evidence if the original schedule was malformed.
Observed Evidence (Live Azure Test — 2026-05-01)¶
# Baseline: * * * * * — executions run every minute
az containerapp job execution list --name job-cron-lab5 --resource-group rg-aca-lab-test5 \
--query "[].{status:properties.status, start:properties.startTime}"
→ Status=Failed StartTime=2026-05-01T03:50:00+00:00
→ Status=Failed StartTime=2026-05-01T03:49:00+00:00
# Execution count before impossible schedule: 2
# Trigger: switch to 0 0 31 2 * (Feb 31 — impossible date)
az containerapp job update --name job-cron-lab5 --resource-group rg-aca-lab-test5 \
--cron-expression "0 0 31 2 *"
# Wait 3 minutes
Execution count after 3 min: 2 ← unchanged
New executions during impossible schedule: 0
# Fix: restore * * * * *
az containerapp job update --name job-cron-lab5 --resource-group rg-aca-lab-test5 \
--cron-expression "* * * * *"
# 75 seconds later
Execution count: 3 ← 1 new execution
[Observed]* * * * *: executions fire every minute (confirmed from job execution list).[Measured]0 0 31 2 *(Feb 31): 0 new executions in 3 minutes (count: 2 → 2). No error or alert surfaced.[Observed]After restoring* * * * *: new execution within 75 seconds.[Inferred]An impossible cron date silently suppresses job execution — the platform accepts the expression without error, but the schedule never fires.
Environment: koreacentral, rg-aca-lab-test5, cae-lab5.
13. Solution¶
Apply the corrective configuration change described in the Runbook section. Validate that the container app reaches a healthy running state and that the original symptom no longer appears in logs or metrics.
14. Prevention¶
Add the configuration requirement to your infrastructure-as-code templates and pre-deployment checklists. Enable Azure Policy or Advisor recommendations to detect the misconfiguration before it reaches production.
15. Takeaway¶
Scheduled Job Missed is a reproducible, configuration-driven failure. The fix is deterministic and low-risk. Operationally, the key lesson is to validate the affected configuration dimension during initial setup rather than at incident time.
16. Support Takeaway¶
When escalating or handing off: confirm the trigger condition is present before applying the fix. Collect logs from the failing revision before deletion. Document the before-and-after configuration in the incident record.
Clean Up¶
- Keep the corrected UTC schedule if the job is real.
- If this was a disposable lab job, remove it through your normal IaC or platform teardown process.