Hey — you asked two things in the same message: why the sync for your three domains fired an hour later than you set it, and whether you should just flip your optimization team over to autonomous while you're in there. They turn out to be the same conversation, so let me take them together instead of firing off two separate answers.
Start with the shape of the system, because it explains both problems. Every team here runs in one of three modes — once, manual, autonomous — and "autonomous" isn't some separate, smarter tier. It's a manual run with a schedule attached and the loop left closed. Same agent, same guardrails, same everything, just a scheduler deciding when to click the button instead of you. Once that's clear, the rest falls into place.
Why your sync and your schedule live in different places
| Schedule | What it drives |
|---|---|
| Data sync | The daily pull of Search Console / Analytics / store data into your dashboards — the fuel for everything else |
| Agent runs | Automatic optimization runs after each sync, research sweeps refilling your brief queue, and any team you leave running |
You'll find sync settings sitting with each domain and run settings sitting with each team — not on one combined automation page, which I know feels off the first time you go looking. It's deliberate, though. Your sync cadence is about the data: how fast Search Console actually refreshes. Your run cadence is about the team: how fast you want that team acting on what it sees. Those are different questions with different answers, and an earlier version of this platform bolted them together on one page, which meant touching either one dragged you into thinking about both. Splitting them was the fix.
One thing worth knowing before you schedule anything for your optimization team: a run that fires on a schedule and a run you start by hand produce the identical object once they're underway. Same report, same history entry, same credit cost, same ability to open it mid-run and watch what it's doing. I've had people assume scheduled runs are a lighter, cut-down version to save cost — they aren't. If you wouldn't trust a run you triggered yourself, don't put it on a timer.
What actually went wrong with your migrated schedule
You mentioned pasting the time straight out of your old tool — 14:00 UTC, meant to land at 2pm your time. That's the exact trap. Our time field wants your local clock, not UTC; it shows the timezone it detected right underneath so you never have to guess. Paste a UTC value in there and it gets treated as already-local, converted to UTC a second time, and you end up with a run at 4pm instead of 2pm. The fix for your other two domains: re-enter the times in local, ignore whatever UTC value the old tool gave you.
The hour you actually asked about — the sync landing at 7am instead of 6 — is a DST artifact, and it's a good one to understand once rather than chase every March and October. Set a 6:00 sync in Berlin in January and the platform stores 5:00 UTC, because Berlin sits at UTC+1 in winter. A naive scheduler would just keep firing at 5:00 UTC forever. Come the DST jump, Berlin moves to UTC+2, and that same 5:00 UTC tick now lands at 7:00 local — quietly, with no error, just numbers a couple hours later than you expect. We convert at entry time against the current offset instead, so a 6:00 schedule means 6:00 wall-clock on the day it runs, DST or not. If you're still seeing a one-hour drift after re-entering the time in local, that's worth a support ticket — it shouldn't happen with a freshly-entered schedule.
Setting the actual cadence
- Sync: daily, no faster. Search Console data ships two to three days behind on a good day. Hourly syncing across your three domains won't get you fresher numbers, it'll just fill the sync history with jobs that fetch the same lagged data over and over.
- Optimization: chained to sync, not clocked separately. This is the part that matters most for what you're about to schedule. If sync finishes at 6:02 instead of 6:00 because Google's API was slow that morning, the optimization run fires right after, on that fresh data — it doesn't wait for its own 6:15 slot and risk running against yesterday's numbers if sync happened to run long. Two independent clocks sound fine until the day they drift apart.
- Research: weekly, sized to what your content team can actually clear. Briefs don't go stale overnight, and unreviewed briefs sitting in a queue still cost credits to produce even if nobody acts on them. If your team can realistically greenlight four or five briefs a week, size the sweep to produce about that — a daily sweep feeding a weekly review habit just builds a backlog nobody ever works through.
- Ads, when you get to that team next month: no schedule, on purpose. Drafts generate on demand; nothing posts or spends without you. The reasoning's in the case against autopilot spend, but the short version is that a scheduling mistake on a content sync is a minor annoyance and a scheduling mistake on ad spend is a bill. Don't expect that team's settings to look like the ones you're setting up today.
So — should you flip optimization to autonomous?
Here's the honest answer, which is less dramatic than the question implies: turning it on changes less than you'd think. The agent doesn't gain any new capability it didn't have when you clicked run yourself — same confirmation gates on anything destructive, same judgment calls, same everything. What changes is only who decides when it acts. Right now, you are. On a schedule, the clock is.
The question I'd actually ask, instead of "is autonomous safe," is this: are you comfortable with the outcome of your last three manual optimization runs happening again, unattended, on whatever cadence you set? If yes, you're ready — turn it on. If you're only comfortable because you personally reviewed each of those three runs before anything downstream happened, that's a real signal, and it means staying manual a little longer is the right call, not a failure of nerve.
Given where you are — three domains just migrated, times not fully settled yet — I'd hold off on autonomous for a few more days. Fix the two remaining schedules, watch tomorrow's sync land at the right hour, run optimization manually two or three more times so you've actually seen what it does end to end. Then schedule it. The cadence questions above get a lot easier to answer with a real run in front of you than they are in the abstract, and there's no cost to waiting a week to get that.
