What are core collaboration hours (and how to set them)?

The promise of a distributed team is that nobody has to be in the same room, or even the same continent. The catch is that some things still need everyone at once. Core hours are how you reconcile the two: a small, protected slice of synchronous time, and a large, generous remainder of async freedom.

What problem do core hours actually solve?

Without a shared window, two failure modes appear. Either people default to "always on", anxiously watching chat in case a colleague three zones away needs them, or coordination grinds to a halt because no two people are reliably awake at the same time. Core hours draw a clean line. Inside the window, expect a reply. Outside it, expect silence, and don't apologise for it.

The point is not more meetings. It is fewer, better-placed ones. Microsoft's 2025 Work Trend Index found that 57% of meetings are ad hoc calls with no calendar invite, the kind of unplanned interruption a clear core window naturally curbs. When everyone knows the only realistic time to talk live is, say, 15:00 to 18:00 UTC, scheduling stops being a negotiation and synchronous time gets spent on the things that genuinely need it.

How do I choose the window?

Start from people, not from a clock you like. The method is the same whether your team spans two cities or two hemispheres.

1. Map everyone's working hours in their own local time. Write down each person's realistic available span, say 09:00 to 17:30, in the zone they actually live in.
2. Find the overlap. Convert each span to a common reference (UTC works well) and look for the hours where the most people are simultaneously inside their working day.
3. Pick two to four hours inside that overlap. Resist the urge to claim the whole overlap. A narrow window is easier to defend and leaves room for the edges.
4. Protect the edges. Don't place core hours right at the start or end of anyone's day. Leave a buffer so a meeting that runs five minutes long doesn't eat someone's dinner.

Finding that overlap by hand is tedious and easy to get wrong, especially with half-hour offsets in the mix. Atlas shows everyone's local time side by side and highlights the window where the team is awake, so you can pick core hours by eye rather than by spreadsheet.

How long should core hours be?

Short. Two to four hours a day is the sweet spot for most teams. A long window quietly becomes a second working day that everyone feels obliged to fill, which defeats the purpose. A short window does three useful things at once:

• It stays defensible across many time zones, where wide overlaps simply don't exist.
• It leaves the majority of each person's day free for uninterrupted deep work.
• It forces synchronous time to be used deliberately, not padded with status updates that could have been a message.

Where do core hours fall for common team shapes?

The right window depends entirely on geography. A few illustrative shapes, assuming roughly 09:00 to 17:00 local working days:

The bottom two rows are the honest cases. When the overlap is one hour or less, a single fixed window will always be unkind to someone. That is where rotation matters.

How do I communicate core hours so they actually stick?

A window nobody can find is no window at all. Make it impossible to miss:

• Write it down once, in a clear reference. State the window in UTC and in each main region's local time, so nobody has to convert under pressure.
• Put it on the calendar. A recurring all-day "Core hours" marker on shared calendars beats a line in a document that gets buried.
• Set the expectation both ways. Inside the window, replies are expected. Outside it, they are not, and a message at 02:00 someone's time should never feel urgent.
• Default to async for everything else. If a decision can wait for the next window, let it. Core hours work because the rest of the day is genuinely free.

For the etiquette of booking inside the window without trampling someone's evening, see our guide to scheduling meetings across time zones without annoying your team.

Common pitfalls to avoid

Most core-hours schemes fail in predictable ways. The window creeps wider until it swallows the day. It lands permanently on one region's evening. It exists in a document but never on a calendar, so people forget. Or it gets treated as "the hours you must be at your desk" rather than "the hours we sync", which kills the async freedom that made the whole idea worthwhile. Guard against all four and the window earns its keep.