Scheduling Experiments

Scheduling lets an experiment launch and end on its own, without a person at the keyboard. You set the start moment and, optionally, an end moment. Times are always shown in the viewer's local timezone, so there's no timezone picker to configure.

Scheduling launch

There are two places to start. While the experiment is a Draft, the Schedule button in the builder header opens the scheduling dialog directly. Alternatively, open the Review & publish step and click Schedule launch in the Pre-Launch Verificationcard above the Publish button. Both share the same pre-launch gate — if the pre-flight checklist is incomplete (for example, the snippet hasn't been detected), Schedule is disabled just like Publish. The dialog asks for two pieces of information:

1. The launch date and time. Pick a date on the calendar, set the hour and minute, and click Done to confirm. Use Reset to clear your selection.
2. Optionally, an end moment (see the next section).

The launch time is always interpreted in your browser's local timezone. The detected zone is shown as a caption below the date input (for example, “Times in your local time — Asia/Dhaka”). Teammates in other countries opening the same experiment see the same launch moment shown in their own local time, automatically — no conversion or coordination needed.

Once saved, the experiment moves to the Scheduled status. The page shows a banner with the next fire moment in the viewer's local time. Cancelling or editing the schedule keeps the experiment a Draft until launch.

Scheduling end

An end schedule can be set in two ways:

• Absolute date — the experiment ends at a specific calendar moment. Same picker as the launch field.
• Relative to launch— the experiment ends N days after launch, at a specific time of day. Useful for “run this for 14 days, ending at 5pm London time.”

Ending an experiment puts it back in the Paused status so you can review and finalise it. Pause is reversible — if results aren't conclusive yet, you can resume the experiment manually.

While an experiment is running, you can attach an end schedule from the results page: click Schedule end next to the Pause button.

Timezones and daylight saving

You don't pick a timezone when scheduling. A vs B detects your browser's timezone, anchors the moment you picked to UTC, and re-derives a local time for every viewer when displaying the schedule. The picker shows your detected zone as a caption so you can confirm what was used.

Daylight-saving is handled at display time, not at storage time. The absolute UTC moment is fixed when you save; each viewer's rendering of it follows their own zone's rules. If your team spans multiple regions, everyone sees the same fire moment in their own local time without anyone having to do arithmetic.

If the platform is down at fire time

Schedules are processed every minute. If the platform misses a fire time because of an outage or maintenance window, A vs B has a 60 minute catch-up window: anything overdue by less than that fires as soon as the worker comes back, with the experiment's actual launch time updated to “now.” Anything older is marked as missed, the experiment stays in its prior status, and the schedule owner gets an in-app notification plus an email.

While a schedule is active

Once a future launch schedule is saved, the Publish experiment button on the Review step is disabled until the schedule fires or is removed. This prevents the accidental case where one person sets a schedule for the weekend and another teammate, not realising, hits Publish on Monday morning.

Clicking the disabled Publish button opens a small popover with a Remove schedule action. Choosing it cancels the pending schedule and immediately re-enables the button so you can launch right now. The dedicated Schedule launch button above Publish stays available the whole time, in case you just want to shift the moment instead of cancelling.

Note that once an experiment is in the Scheduled status, the builder header no longer shows Publish or Schedule buttons. Schedule management for a scheduled experiment lives in the Scheduling card on the Review step, via the banner's Edit and Cancel actions.

The guard is enforced at the API as well as the UI. Calling POST /experiments/{id}/launch while a future schedule is active returns HTTP 409 with an error code of schedule_conflict. Cancel the schedule first, or wait for it to fire.

Cancelling or editing

From the experiment dashboard, the scheduled banner exposes Edit and Cancelbuttons. Cancelling clears both the launch and end portions of the schedule; editing opens the same dialog you used to create it. You can cancel the end portion of a running experiment without affecting how it's running today.

Notifications you'll get

When a schedule fires (launch or end), the user who scheduled it receives both an in-app notification (the bell icon in the top bar) and a transactional email. The same channels surface missed and failed events.

See Notifications for the full list of notification types and how to mark them read.

Permissions

Creating, editing, and cancelling experiment schedules requires the publishProductioncapability — the same permission used for manual launches. By default, A vs B fires schedules using a snapshot of the scheduler's permissions at the time of scheduling. Organisations can opt into strict permission mode which re-checks the scheduler's capability at fire time and marks the schedule as failed if it has since been revoked.