Give delivery work a steady rhythm.
Cycles are repeating, time-boxed windows for making and reviewing delivery commitments. A cycle does not replace a task's planned date: Telos derives cycle membership from that date and the applicable team schedule.
A schedule, not another date field
Each enabled cycle grid repeats from one UTC calendar anchor. Tasks whose planned start falls inside a generated window belong to that cycle. Work in a cooldown gap, beyond the generated horizon, or owned by a team without cycles remains outside a cycle.
Open the dedicated Cycles tab under Execution to review the current and upcoming windows, their work, and commitment state. Cycle history remains available after a window closes.
Configure cycle planning
Workspace members with cycle-management access configure cycles under Settings → Cycles. Turn cycles on, choose whether the workspace shares one organisation schedule or each team owns its own, then select a start date and cadence.
The selected start date is interpreted as a UTC calendar day and anchors the repeating schedule. Organisation mode has one start date; team mode gives every team row its own persisted start date. When changing an existing grid, choose a boundary that does not cut through that grid's active cycle. Telos preserves the current window rather than changing its identity or dates in place.
Duration, cooldown, and upcoming horizon
Duration is the length of every delivery window. Choose one through eight weeks.
Cooldown is the gap between windows: no cooldown, one week, two weeks, or three weeks. Cooldown dates belong to no cycle, leaving explicit space for planning, reviews, maintenance, or debt work without adding it to a delivery commitment.
Upcoming cycles controls how many active or future windows Telos keeps generated. Increase it when the team needs a longer concrete planning horizon; work beyond that horizon remains planned by date but has no cycle yet.
Each team keeps its own rhythm
Team mode is opt-in per team. Every row has its own UTC start date, duration, cooldown, upcoming count, and auto-rollover choice. Two teams can therefore follow different anchors as well as different cycle lengths. The switches in the Enabled and Auto-rollover headers apply that choice to every team row; row switches remain available for exceptions.
Turning one team off stops new windows and live task binding for that team, but retains its cadence preferences and start anchor. Re-enabling the team restores those choices unless an administrator changes them before saving. A task with no eligible enabled team schedule has no cycle.
Choose what happens to unfinished work
Auto-rollover is independent for every team schedule, or a single choice for an organisation-wide schedule. When enabled, unfinished work moves forward one window after a cycle ends. When disabled, the ended cycle waits for a person to roll it over. Changing this preference does not rebuild the calendar.
Rollover preserves the record of the closed cycle and its commitment verdict. It moves live unfinished work; it does not rewrite completed-task history.
Disable without erasing the record
Turning cycles off stops generation and live cycle binding across the workspace. Existing cycle records, history, commitments, and verdicts are preserved, but the in-app Cycles tab and surface stay hidden until cycles are re-enabled. Turning cycles back on uses the saved configuration, while a new selected start date provides the safe boundary for any regenerated future schedule.
Show cycle context on the timeline
The Planning timeline remains date-first. When cycle planning is enabled, its local Show cycles toggle adds a compact, neutral cycle strip between the toolbar and the existing date axis for the selected teams. The strip has its own space: it never overlays task bars. It is off by default and does not change task dates, dependencies, or cycle configuration.
Bring cycles over from Linear
The Linear API importer can bring over selected teams' cycle schedules, historical windows, current cycle membership, and bounded slip history. Imported past windows are closed history; current and future windows remain open, and Telos does not invent commitments or verdicts for work agreed in another system.
Jira remains available for work import, including issues, epics, labels, components, and comments. Sprint history is not imported yet, so Jira work arrives without cycle membership or slip counts. Jira Software sprint API support is deliberately deferred until Telos can request and explain its separate permissions reliably.