One account clock, several workers

Weekly work is aligned to the account creation clock rather than assigning an unrelated weekday to every module. The next boundary is the first future seven-day interval from account creation. Alignment means the jobs become due together; it does not mean a website crawl, AI collection, catalogue analysis, and score calculation can finish in the same second.

Example
Scheduling model
anchor = account creation time
period = 7 days
next due = first anchor + n × period strictly after now

If several boundaries were missed, advance to the next future boundary.
Do not start a burst of one job for every missed week.

Which work follows the weekly boundary

Eligible weekly AEO model tests, Commerce Intelligence, Trend Intelligence, full technical audits, website knowledge refreshes, opted-in weekly AI-search work, and scheduled Berater work use the aligned schedule where enabled. Existing package access, budgets, approval requirements, provider availability, and disabled schedules still apply. Synchronising the clock does not switch on an unavailable module or approve a new experiment.

What does not wait for that boundary

Initial setup, an explicitly requested manual run, bounded retries, event-driven recomputation, and continuous chat or lead activity have different triggers. Connector ingestion can have its own cadence. A deliberately configured non-weekly schedule is not evidence that the weekly clock is broken. An initial website audit can be prepared by a worker after connection even before its first weekly refresh.

Dependencies and partial readiness

Collection usually precedes extraction; extraction precedes aggregate metrics; downstream insights use the evidence that is ready. One slow or failed provider can delay part of a measurement. A crawl may complete while indexing is still pending. Read the module's requested, collected, processed, and eligible counts instead of interpreting one spinner as all modules being unavailable.

Reading the dashboard and starting work

Opening a results page normally reads stored state and job progress; it is not a reason to launch a new paid model measurement. If a processing screen appears unexpectedly, inspect the run's start time and trigger: scheduled refresh, initial setup, manual request, or retry. Leaving the page does not stop a server-side job. Use an explicit stop action only when you intend to cancel further work; an already dispatched provider request may still complete.

Retries preserve identity

A retry should continue the intended run and reuse checkpoints where supported rather than duplicating every answer. A network timeout does not prove the provider performed no work. Job state, request identity, and saved outputs matter when deciding whether another external request is necessary. Repeatedly reloading or starting new measurements can complicate diagnosis without repairing the original failure.

Compare completion windows, not refresh animations

A shared schedule is not a shared statistical denominator. AEO, Commerce, Search Console, and interaction events still have different populations and source periods. For trend comparisons, keep question versions, models, region, language, method, and formula compatible. A completed weekly refresh does not make an incompatible prior run a valid baseline.

What to do when results are still being preparedCockpit periods, Search Console, and connector freshnessComparable measurements, repeated sampling, and uncertainty