Skip to main content

Understand Flock

Scheduled reviews

Keep a useful review running over time. Make its setup repeatable, choose a cadence, and inspect the evidence from each occurrence.

Repeat a useful review

A scheduled review reuses a saved launch setup to revisit a target over time. Start with a review you have inspected: a signup journey, a pricing page, or an important authenticated workflow. Make sure its inputs and sign-in can support another attempt before scheduling it.

For example, review a stable staging signup every week with the same personas, goal, and limits. Use the new evidence and comparison to investigate changes. The GitHub App serves a different trigger: reviewing configured pull-request previews when code changes.

Create the schedule from a review

  1. Open the review and find Schedule beside its saved setup controls.
  2. Choose Cadence: Daily, Weekly, Every x days, or Every x weeks. For an interval-based cadence, enter the interval. Day intervals support 1–365; week intervals support 1–52.
  3. Choose the Timezone. The initial value follows your browser’s timezone; confirm it is the one your team intends.
  4. Choose Time: No preference, Morning, Afternoon, Evening, or a specific time. A specific time adds the Exact time input.
  5. Choose Create. Inspect the saved schedule and its next due time.

An existing schedule appears as Scheduled rather than creating a second active schedule for the same source review. These controls require workspace permission and a reusable saved setup. Example reviews cannot be scheduled.

Understand the timing

The cadence and time preference determine when an occurrence is due in the selected timezone. Morning, Afternoon, and Evening currently anchor to 09:00, 13:00, and 18:00 respectively; No preference uses midnight when computing the due time.

A due time is not a guarantee that browser execution starts at that exact minute. The service processes due work, checks admission, and submits a review. Read the schedule’s actual occurrence status and linked review to understand what ran.

What the schedule reuses

The saved setup supplies the target, scope, goal, completion criteria, boundaries, input policies, personas, authentication configuration, and execution limits. A schedule created from the review uses that source review as its comparison reference. Each occurrence submits another review rather than updating the original review’s evidence in place.

Generated inputs are materialized for a new attempt according to their generation policy. Reviewer-choice values can be chosen again. Supplied reusable values stay part of the setup. A value marked One-time cannot simply be reused by a schedule.

Keep the target reachable and its test data suitable for repeated attempts. A one-time invitation, expired login, consumed signup value, or missing setup can block replay. Run again and Schedule show the setup’s availability; use the offered setup repair flow when needed.

Scheduled launches still go through admission checks. A saved schedule does not bypass workspace permissions, current account or usage requirements, target acknowledgement, or sign-in readiness. Check the original review’s usage estimate and your account’s current terms when deciding on a cadence.

Monitor, pause, and end

Open Schedules in the dashboard to inspect the cadence, next due time, warnings, occurrence history, and links to submitted reviews. Submitted means the review was handed off; inspect the resulting review to establish completion and its outcome.

  • Pause stops future scheduled activity while keeping the schedule available to resume.
  • Resume reactivates a paused schedule after its setup is checked.
  • End ends the schedule. Create a new schedule when you want a new recurring setup.
  • Archive is available for ended schedules to remove them from the active list. Restoring an archived schedule changes its visibility, not its ended status.

Inspect failures and missed or skipped occurrences instead of assuming that an active schedule means every review completed. Repair the target, sign-in, setup, or account requirement identified by the dashboard before relying on the next occurrence.

Use the findings, not just the recurrence

Open each useful result, compare the evidence, and triage its findings. A matching persistent deferral can keep known future work marked Deferred while leaving it visible. A changed score is a signal to inspect the run; it is not proof of a regression by itself.

Use a stable scheduled target to follow the experience over time, and use pull-request review to put evidence beside a proposed change. Both need an appropriate target and reviewers. Neither establishes coverage of every page, persona, or possible regression.