Product feature
Scheduled changes
Queue a flag to turn on or off at a future time and let Featureflip flip it for you. No cron jobs, no CI wiring, no one awake for the cutover.
Last updated:
A scheduled change queues a feature flag to turn on or off automatically at a future time you choose. You set the target state and the moment, in your local time, and Featureflip applies the change for you server-side — so nobody has to be online for a timed launch, an end-of-promo cutoff, or a 2am maintenance window. When it runs it behaves exactly like a manual toggle: it streams to your connected SDKs within seconds and is recorded in the audit log under your name. Schedules are set per flag per environment, and you can cancel a pending one any time before it applies.
How Featureflip's scheduled changes work
The pieces that turn "flip this on Friday at 9am" into a change you set once and let the platform run — without a cron job or a calendar reminder.
Turn a flag on or off at a future time
Pick the target state and the moment, in your own local time, and Featureflip flips the flag for you when it arrives. A timed launch, a promo that ends on Sunday night, or a maintenance window becomes a schedule you set once and forget, instead of a calendar reminder to log in and toggle.
Nothing to keep online
The change is stored server-side and applied by Featureflip at the scheduled time. There is no cron job to write, no CI pipeline to wire up, and nobody has to be awake or at a keyboard when the moment comes. Schedule a 2am cutover from your desk in the afternoon.
Set per environment
Schedules are attached to a flag in a specific environment, so you can queue a production cutover without touching staging. Each environment carries its own independent set of scheduled changes, the same way it carries its own flag states and targeting rules.
Cancel any time before it runs
A queued change shows as Pending, with its target state, the time it will apply, and who scheduled it. Plans change — cancel a pending schedule with one click any time before the moment it is due, and nothing happens.
Applied exactly like a manual toggle
When the time arrives, Featureflip re-runs the real change on your behalf, so the same guards, audit logging, and live streaming fire as if you had flipped the flag yourself. The audit log records it under your name, and connected SDKs pick it up over their streaming connection within seconds.
A clear, honest history
Every schedule ends in one of three states: Applied when it ran, Cancelled when you called it off, or Failed with a reason if something blocked it. A scheduled change is never silently dropped — you can always see what was queued, what happened, and why.
For the click-by-click walkthrough — scheduling a change, watching it apply, and cancelling one — see the scheduled changes guide.
Scheduling a change, step by step
The same four moves cover a timed feature launch, a promotion that ends at midnight, and a maintenance window you set up the afternoon before.
- 1
Open the flag and pick the environment
Scheduled changes are per environment, so start on the environment tab where you want the change to happen — Production, Staging, or any environment in the project. What you schedule here applies only to that environment.
- 2
Click "Schedule…" and choose the change
Set the target state — Turn ON or Turn OFF — and the time it should happen, entered in your local time. Featureflip only accepts a moment in the future, so a schedule can never be queued for a time that has already passed.
- 3
The change waits as Pending
Your queued change appears in the flag's Scheduled changes panel with its target state, the time it will apply, and who created it. It sits there, doing nothing to your live flag, until the moment arrives — and you can cancel it at any point up to then.
- 4
It applies automatically and is recorded
At the scheduled time Featureflip flips the flag, streams the new state to every connected SDK, and writes the change to the audit log under your name. The entry moves to Applied — or to Failed with a reason if something prevented it, so you are never left guessing.
What happens when a scheduled change runs
A scheduled change is not a separate, lesser code path. At the chosen moment Featureflip re-runs the same flag change you would have made by hand, which means every safeguard around a normal toggle applies to a scheduled one too:
- It streams to your SDKs live. The new flag state propagates to every connected SDK over its open streaming connection within seconds, the same as any dashboard change — your app sees the flip without a redeploy or a restart.
- It lands in the audit log under your name. The change is recorded against the person who scheduled it, so your flag history shows who queued it and when it applied, not an anonymous system entry.
- The rest of evaluation is untouched. Turning a flag on schedules whether it is on, not how it evaluates. Your targeting rules, percentage rollout, and prerequisites all still apply exactly as they would after a manual flip.
- Failures are visible, not silent. If something blocks the change when it is due, it is marked Failed with a reason rather than quietly skipped, so a scheduled cutover can never disappear without a trace.
The result is a way to move a release off the clock and off your shoulders: pair a scheduled flip with a progressive rollout to start a ramp at a fixed time, or with a kill switch to end a limited-time feature the moment it should stop.
Frequently asked questions
- What are scheduled changes?
- A scheduled change queues a feature flag to turn on or off automatically at a future time you choose. Instead of logging in at the exact moment to flip a flag, you set the target state and the time up front, and Featureflip applies the change for you when it arrives. The change is stored server-side, so nobody needs to be online for it to run. When it applies, it behaves exactly like a manual toggle: it streams to your connected SDKs within seconds and is recorded in the audit log under the person who scheduled it. Schedules are set per flag per environment, so you can queue a production cutover without affecting staging.
- Can I schedule a flag to turn on and then off, like a maintenance window?
- Yes — you schedule each change separately. For a maintenance window you would queue one change to turn the flag off at the start and a second change to turn it back on at the end. Both sit as Pending until their times arrive and apply independently, and you can cancel either one beforehand if the plan changes. Because each side of the window is its own scheduled change, you can also move just one of them without touching the other.
- What happens if I am offline when a scheduled change is due?
- Nothing changes about how it runs. Scheduled changes are applied by Featureflip on the server at the time you chose, so they do not depend on your browser being open, your laptop being awake, or anyone being at a keyboard. You can schedule a middle-of-the-night cutover during the working day and log off — the flag flips on its own, streams to your SDKs, and lands in the audit log whether or not you are watching.
- Can I cancel or change a scheduled change?
- You can cancel any scheduled change while it is still Pending — it appears in the flag's Scheduled changes panel with a cancel action, and cancelling it means it will never apply. To change the target state or timing, cancel the pending change and schedule a new one with the details you want. Once a change has already applied, it is part of the flag's history and is shown as Applied rather than something you can undo — flip the flag again, or schedule a new change, to move it back.
- Is a scheduled change audited?
- Yes. A scheduled change is applied by re-running the real flag change on your behalf, so it goes through the same path as a manual edit — including the audit log. The entry is recorded under the person who scheduled it, not an anonymous system account, so your flag history and Audit Logs page show who queued the change and when it took effect. That keeps the record of who changed what intact even when the change was set up hours or days in advance.
- Do scheduled changes still respect targeting rules and prerequisites?
- Yes. A scheduled change only sets whether the flag is on or off in an environment — it does not bypass the rest of evaluation. When the flag turns on, your targeting rules, segments, percentage rollout, and prerequisites all still apply at evaluation time exactly as they would after a manual toggle. Scheduling changes when a flag is evaluated, not how, so the same flag can be scheduled on and still serve its off variation to users a rule excludes.
Schedule your next flip from your desk
Set the state and the time; Featureflip handles the cutover. Start free on the Solo plan — no credit card, and flat pricing with no per-seat fees on paid plans.
Related
Scheduled changes (guide)
A step-by-step walkthrough of scheduling a change, watching it apply, and cancelling a pending one.
Kill switch (use case)
Turn a feature off in seconds — manually now, or on a schedule when a limited-time feature should end.
Percentage rollouts (feature)
Start a gradual ramp at a fixed time by scheduling the flag on, then climbing the slider.
Audit log (docs)
Every scheduled change is recorded under the person who queued it, with the time it applied.