Schedule

Scheduled tasks let Kiro Web run a prompt against your GitHub or GitLab repositories on a schedule, without you starting a session. You describe the work once, choose when it runs, and Kiro carries it out in autonomous mode. The agent reads the code, makes changes, and opens a pull request or merge request when there's something to review. Scheduled tasks are useful for recurring maintenance work like generating changelogs, triaging new issues, updating dependencies, or summarizing merged pull requests.

Scheduled tasks are available on Pro, Pro+, Pro Max, and Power plans.

Open Schedule from the left sidebar in app.kiro.dev to see everything you've created. Each row shows the task's name, a preview of its prompt, the connected repositories, its schedule, and its current status. Use the search box to find a scheduled task by name, or the status filter to narrow the list by state.

A scheduled task is either Active (enabled and running on schedule) or disabled. Disable a scheduled task to pause its runs without deleting it — re-enable it anytime from the Edit screen or the row's status toggle.

From the Actions menu (the ⋯ button) on any row, you can:

• Edit — change the name, prompt, repositories, status, or schedule.
• Delete — remove the scheduled task. This stops all future runs.

1. From the Schedule page, select Create scheduled task.
2. Give the task a Task name so you can recognize it in the list.
3. Leave Status set to Enabled to have it run on schedule, or disable it to save it without running.
4. In the Prompt field, describe what the task should do. Be specific about the task and the expected output, since the task runs without anyone there to clarify. Prompts can be up to 10,000 characters.
5. Select one or more repositories using Select repo.
6. Add one or more schedules to control when it runs (see Schedules).
7. Select Create scheduled task.

The prompt is the full instruction set for the run, so treat it like a brief for an unattended task. State the goal, the repository conventions to follow, and what Kiro should produce.

For example, a scheduled task that maintains a changelog might use a prompt like:

Find all pull requests merged to the main branch since yesterday.
Summarize each PR in one line following the format in CHANGELOG.md.
Group changes under "Added", "Changed", and "Fixed" headings.
Open a pull request that appends today's entry to the top of the changelog.
If no pull requests were merged, do nothing.

The last line is important. Telling Kiro to only act when there's relevant work avoids empty pull requests on quiet days.

Each scheduled task runs on one or more schedules. You can add up to five schedules per task, and each one can use a different cadence. Select + Add schedule to add another.

Every schedule offers three modes:

• Hourly — runs at the top of the hour, at an interval you set with Run every (for example, every 1 hour or every 6 hours).
• Daily — runs once a day at a time you choose.
• CRON — runs on a custom cron expression for full control over the cadence.

Custom schedules can run at most once per hour. Kiro flags a CRON expression that would run more frequently and prevents submission until you correct it.

As you configure a schedule, Kiro shows the generated cron expression beneath it, so an hourly schedule displays Generates: cron(0 */1 * * ? *). Schedules are evaluated in UTC. In the scheduled tasks list, a schedule's next run is shown in your local time alongside its UTC equivalent, for example At 9:00 AM (1:00 PM UTC).

Each time a scheduled task runs, it creates a session visible in your session list alongside interactive sessions. Open a run's session to see exactly what Kiro did: the conversation, the steps it took, and any pull request it opened. This is the best way to confirm a scheduled task is behaving as expected or to troubleshoot a run that didn't produce the changes you wanted.

When a scheduled task produces changes, Kiro opens a pull request (GitHub) or merge request (GitLab) in each affected repository. Review them, leave feedback, and merge when you're satisfied. Because the work lands as a pull request or merge request rather than a direct commit, nothing reaches your main branch without your review.

• Autonomous mode — how the agent plans and executes tasks end-to-end
• Steering the agent — guide scheduled task behavior with persistent conventions
• Sandbox — the isolated environment where scheduled tasks execute