### Schedule timing
* **Start**: choose **Immediately** to begin as soon as the rule is published, or **On date** to delay activation. The rule stays disabled until the start date.
* **Duration**: the total length of the ramp. In **Simple View** you set it directly and GrowthBook spaces the steps to fit; in **Advanced View** it shows a computed summary of your steps, such as "\~5d + monitored steps".
* **Disable on date**: click **+ Disable on date** to set an optional date that turns the rule off whether or not the ramp has finished. Use it for time-boxed rules.
### Lock feature while running
Turn on **Lock feature while running** to block publishing other draft changes to the feature while the ramp is actively progressing. This keeps manual edits from competing with the schedule.
| Status | Meaning |
| - | - |
| `pending` | Created but not yet armed. Publish the revision to start. |
| `ready` | Armed and waiting for the start date. |
| `running` | Actively advancing through steps. |
| `paused` | Halted by a user or a `hold` health action. Resume to continue. |
| `completed` | All steps applied and the end state set. |
| `rolled-back` | Returned to the pre-ramp state. |
From the UI or API you can start, pause, resume, manually advance, jump to a specific step, approve a gated step, roll back to the pre-ramp state, or restart a finished schedule. Every transition is recorded in the schedule's event history.
### Editing a rule under a running schedule
A schedule stores the rule's pre-ramp state as its **base state** and re-applies it, plus every step so far, each time it advances. While the schedule is `running`, the rule cannot be edited: the rule editor locks the rollout percentage, targeting, and value, and a publish that changes the rule is refused with the schedule's pause route. Pause the schedule first. A schedule with no steps (enable now, disable on a date) never locks its rule.
While it is `paused` (or `ready`, before it starts), publishing an edit to the rule reconciles it with the plan:
* A field the plan sets in a step or its end state, usually the rollout percentage (`coverage`), is refused with the step named; change it in the plan instead.
* Any other change to the rule's targeting or value is written into the base state, so it applies immediately, survives the remaining steps once you resume, and is what a rollback restores.
* Some older schedules share one base state across a rule's per-environment copies (for example `fr_1__dev` and `fr_1__production`). A change that would leave those copies different is refused, since the shared base state would apply it to all of them. Remove the ramp from the rule, publish the change, then attach a new schedule.
Removing a schedule needs no approval: `eject-target` and `DELETE` leave the rule as it is right now, so a ramp can always be cleaned up.
Reverting the Feature Flag to a revision published before a schedule was attached removes that schedule from the rule, and deletes it once it controls no rules; you're warned first. A running schedule still needs pausing before the revert, like any other change to its rule. A scheduled or auto-published revert fails instead of removing a schedule attached after its draft was created, so publish that one manually to confirm.
## Templates
Use **Save as template** to store a schedule's steps and end state as a **Ramp Schedule Template** and reuse them across features. Apply a template when you create a schedule to inherit its steps, then override any of them as needed.
## Managing via the API
The recommended way to attach a ramp schedule to a rule, or to change the plan of one that is already attached, is through a draft revision. The plan is then reviewed and published like any other rule change, and the scheduler carries it out step by step afterwards.
```bash theme={null}
# Stage a three-step ramp on a rule in a new draft; the final step waits for approval
curl -X PUT https://api.growthbook.io/api/v2/features/checkout-v2/revisions/new/rules/fr_abc123/ramp-schedule \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"steps": [
{ "interval": 3600, "actions": [{ "patch": { "coverage": 0.1 } }] },
{ "interval": 86400, "actions": [{ "patch": { "coverage": 0.5 } }] },
{ "interval": null, "holdConditions": { "requiresApproval": true },
"actions": [{ "patch": { "coverage": 1.0 } }] }
]
}'
# Publish the draft (goes through review if the project requires it)
curl -X POST https://api.growthbook.io/api/v2/features/checkout-v2/revisions/