Claude Code Scheduled Task Didn't Run? Verify It Safely

If a Claude Code scheduled task or Routine appears to have run but produced no useful result, do not trust the schedule badge alone. First identify which scheduler you created, run a read-only canary on demand, inspect the resulting session, then require an explicit completion receipt from the real task.

The success condition is simple: one manual canary and one scheduled canary each create a reviewable run with the expected repository, commit, tools, timestamp, and output. Only then should you enable writes or external side effects.

Why "Scheduled Task" Can Mean Three Different Things

Claude currently has several scheduling surfaces with different lifetimes and dependencies. A task that is working as designed in one mode can look broken if you expect another mode's behavior.

Cloud Routines persist independently of a terminal. By contrast, /loop tasks are session-scoped, wait while Claude is busy, and recurring tasks expire after seven days. Desktop tasks that depend on local files or apps cannot run when that local environment is unavailable.

Before troubleshooting, write down which surface created the task. Do not delete local task files or recreate the schedule until you know whether the active task is local, cloud-hosted, or session-scoped.

Recent Reports Are a Reason to Verify, Not a Failure Rate

Public Claude Code issue reports from July 28 through July 30, 2026 describe several distinct symptoms: a lastRunAt value advancing with no session or output, one-shot tasks that never dispatched, tasks interrupted during a tool call but recorded as successful, and scheduled slots firing more than once. These are user reports, not an Anthropic-confirmed root cause or a measured platform-wide failure rate.

The reports still reveal an important operational gap. A scheduler can record trigger state without proving that the intended work completed. Your verification must cover three separate boundaries:

1. The trigger exists and became due.

2. A run session actually started with the expected dependencies.

3. The intended outcome completed exactly once.

Prerequisites

For a Claude Code cloud Routine, you need:

• a current Claude Code installation signed in with a Claude subscription;

• the intended GitHub repository connected to Claude;

• any required connector added to the Routine, not only to your local CLI;

• permission to view and manually run the Routine;

• a read-only canary that cannot push, deploy, message people, or change external data.

Check the local command before using /schedule:

claude --version

If /schedule is unknown, the current Anthropic troubleshooting guide says to check the login method, organization policy, and environment flags that disable feature fetching. You can still inspect cloud Routines at claude.ai/code/routines.

Step 1: Confirm the Saved Routine and Trigger

In Claude Code, open the schedule manager:

/schedule list

You can also open the Routine at claude.ai/code/routines. Confirm all of these fields before changing anything:

• the Routine is enabled;

• the schedule trigger still exists;

• the next run is shown in the expected local timezone;

• the intended repository and environment are selected;

• only the required connectors are included;

• account usage has room for another Routine run.

Expected result: the saved trigger, next run, repository, and environment match your intent. A one-off that already fired should be marked as ran and disabled. A Routine with only an API or GitHub trigger can correctly have no next scheduled time.

Cloud scheduled runs may start a few minutes after the selected time because Anthropic staggers them. A short delay is not the same as a missing run. For /loop, recurring tasks can fire up to 30 minutes after the nominal time, wait for the current turn to finish, and do not replay every missed interval.

Step 2: Replace the Real Job With a Read-Only Canary

Do not debug a failed schedule by repeatedly sending emails, pushing branches, creating tickets, or changing production data. Temporarily use a canary that proves the execution environment without changing it:

Read-only scheduling canary.

In the selected repository:
1. Run `git rev-parse HEAD`.
2. Run `git status --short`.
3. Return exactly these receipt fields:
   RUN_STATUS=ok
   REPOSITORY=<owner/name>
   COMMIT_SHA=<full SHA>
   WORKTREE_CLEAN=<yes or no>
   COMPLETED_AT_UTC=<ISO

Expected result: the run returns a complete receipt. For a cloud Routine, the commit should belong to the freshly cloned repository and normally starts from its default branch unless your prompt specifies otherwise.

The receipt matters more than a generic "completed" state. It proves which repository and revision the run inspected, whether the environment was clean, and when execution reached the end.

Step 3: Run the Canary on Demand

Use Run now on the Routine detail page or manage existing Routines from Claude Code:

/schedule run

Open the new run session. Check the receipt itself, not only the status shown in the list.

Expected result: one new session appears, the canary commands complete, and every receipt field is present. If no session appears, preserve the Routine ID, trigger, expected time, timezone, and screenshots before editing the schedule.

If the manual canary fails, the schedule is not yet the interesting variable. Fix the repository, connector, environment, policy, network, or usage problem first. If the manual run succeeds but the next scheduled canary does not start, you have isolated the trigger or dispatch path.

Step 4: Verify the Scheduled Path Separately

Leave the same read-only canary enabled for the next real trigger. Do not change its prompt, repository, connectors, or environment between the manual and scheduled tests.

After the trigger window:

1. Confirm exactly one new run session exists.

2. Compare its receipt with the manual run.

3. Confirm the scheduled run used the expected repository and commit.

4. Check that its completion timestamp falls after the scheduled start.

5. Record any stagger separately from execution duration.

Expected result: the scheduled path produces one complete receipt without a manual click. A run that started but lacks its final receipt is incomplete even if the surrounding UI says it succeeded.

Step 5: Check Cloud Dependencies in the Right Place

Cloud Routines do not automatically inherit every local Claude Code dependency.

Repository access

Each Routine run clones its selected repository. Check that GitHub is connected and that the Routine names the correct repository. GitHub event triggers also require the Claude GitHub App; running /web-setup alone does not install that event-delivery app.

Connectors and MCP servers

An MCP server added locally with claude mcp add lives on your machine. It does not automatically appear in a cloud Routine. Add the service as an account connector or use an reviewed .mcp.json committed to the repository when that is appropriate.

Network access

The cloud environment applies its own network policy. A request to a host outside the allowlist can fail with 403 and host_not_allowed. Add only the domain the Routine needs, or use the corresponding connector when available. Do not switch to unrestricted network access merely to hide which dependency failed.

Usage and policy

Routines have account-level run limits in addition to normal subscription usage. Organization owners can also disable Routines. A rejected run caused by either boundary is not fixed by recreating the prompt.

Common Failure Modes

Add a Completion Receipt to the Real Task

Once both canary paths pass, restore the real prompt but keep a machine-checkable receipt. Include fields that prove the intended result, not just agent activity:

At the end, return:
RUN_STATUS=ok|failed
SCHEDULED_FOR=<ISO 8601 timestamp>
COMPLETED_AT_UTC=<ISO 8601 timestamp>
INPUT_COUNT=<integer>
OUTPUT_URL=<canonical URL or none>
SIDE_EFFECT_KEY=<routine-name>:<scheduled timestamp>

For a reporting task, the output URL might point to the generated report. For a pull-request task, it should be the actual pull request, not a prose statement that one was created. For a read-only monitor, return the exact window and item count.

This pattern also makes notifications useful. A completion alert should carry the receipt or run link so you can distinguish "the scheduler woke up" from "the job finished." See the Claude Code task notification guide for local completion signals, and use the AI coding-agent verification checklist before trusting code changes.

Verify an External Action Before Scheduling It

If the Routine depends on an external service, test that dependency read-only before putting it behind a timer. Aident Loadout keeps supported provider credentials in Vault and lets you inspect an Action's typed inputs before execution.

Install or update it by giving your agent this exact instruction:

Follow https://aident.ai/SETUP.md

Then verify the account, Vault, and one read-only Action:

aident account auth status
aident vault vault --action status
aident capabilities search \
  --query "search Hacker News stories" \
  --types '["action"]' \
  --limit 5
aident capabilities get --name "<EXACT_ACTION_NAME_FROM_SEARCH>"

Inspect the returned schema, supply only its required read-only fields, and execute it once. Expected result: one successful response without a provider API key in the prompt, shell history, or repository. This proves the external dependency separately from the scheduler.

Use Aident Loadout to verify one read-only Action before you schedule it.

Why This Verification Works

A schedule record proves intent. A run session proves dispatch. A completion receipt proves the task reached its required outcome. Testing those boundaries separately prevents a saved trigger, advanced timestamp, or optimistic success label from standing in for completed work.

The method follows the repeatable structure behind Aident's Ollama networking guide: use the exact symptom, run one bounded diagnostic, state the expected result, isolate dependencies, and explain why the evidence is sufficient. It does not assume every scheduled task is unreliable. It makes unattended work observable before the consequences become expensive.

Sources

• Automate work with Routines, Anthropic Claude Code documentation, accessed July 31, 2026

• Run prompts on a schedule, Anthropic Claude Code documentation, accessed July 31, 2026

• Schedule recurring tasks in Claude Cowork, Anthropic Help Center, accessed July 31, 2026

• Scheduled one-shots failed to dispatch or complete, Anthropic Claude Code issue, opened July 30, 2026

• Scheduled task advanced without a session or output, Anthropic Claude Code issue, opened July 28, 2026

• Scheduled tasks fired more than once per slot, Anthropic Claude Code issue, opened July 30, 2026

Refresh this guide when Anthropic changes Routine commands, scheduling surfaces, run-status semantics, cloud environment behavior, /loop lifetime or jitter, or resolves the linked issue reports with a verified fix.