Expiration and Page Freshness
Aura has two features for stale content, and they do different jobs. State expiration moves a page out of its current state once a deadline arrives — it changes the workflow. Page freshness is a passive signal that flags whether the page has drifted from its last approved version — it never moves the page. Workflows can use one, both, or neither without interference.
State expiration
Section titled “State expiration”State expiration is configured per state in the Events section of the state sidebar in the Workflow Builder. Choose between a duration (move the page after a fixed time in the state) or a date (move the page on a specific calendar day), pick a target state, and optionally send a notification email before or after expiration. See the Workflow Builder guide for the layout.
When expirations fire
Section titled “When expirations fire”Expirations are not scheduled per page. Aura scans every workflow instance with a passed deadline on an hourly cadence and processes them in a batch. A page never expires exactly on the configured timestamp — it expires at the next hourly tick. A duration of “1 day” set at 14:23 fires some time after 14:00 the next day, not at 14:23 sharp. Plan around this when durations land near a meaningful boundary.
The clock for a duration starts when the page enters the state, taken from the timestamp of the transition that brought it there. If a page leaves a state and later re-enters it, the clock restarts from that re-entry. Aura recomputes the deadline on every state entry, regardless of whether it’s the same state. There is no “remember the original deadline” mode.
Date-based expirations are interpreted in UTC. “1 December 2026” in the builder means a deadline of 2026-12-01 00:00:00 UTC, picked up by the hourly scan shortly after.
With Repeats annually enabled, Aura rolls the configured day forward to its next future occurrence each time the page enters the state. An annually repeating “1 December” set on 5 December schedules for 1 December the following year.
The reminder email
Section titled “The reminder email”The reminder configured under Send email before expiration is computed once, at state entry, by subtracting the offset from the deadline. If the offset exceeds the time remaining — a 7-day reminder on a state that expires in 2 days — the reminder timestamp falls in the past and sends on the next hourly run. Each reminder is tracked per instance: once sent, it won’t be re-sent for the same state entry, even if the page lingers. A new reminder is scheduled when the page transitions out and back in.
Recipients (Author, Owner, Last editor, plus specific users, groups, or email addresses) are resolved when the reminder fires, not at state entry. A page whose owner changes between state entry and reminder time emails the new owner. If recipient resolution returns nobody — for instance, a deactivated owner — the reminder is skipped silently. When Bundle notifications is enabled in the global app config, the reminder is recorded for the daily digest rather than sent immediately; see Emails for that flow.
What the hourly scan does and doesn’t do
Section titled “What the hourly scan does and doesn’t do”If the current state no longer has an active expiration configuration when the scan runs — typically because the workflow was edited to remove it — Aura clears the stale deadline on the instance and moves on. The page does not transition. The same applies if the configuration is still present but flagged inactive.
When the target transition state has been deleted from the workflow, the expire transition fails for that instance and the failure is logged; other expirations in the same batch are unaffected. If the workflow has been removed from the page entirely, the instance no longer exists and is never visited. Edits in progress at the moment of expiration don’t block the transition — the expire runs as the app, and Confluence handles the concurrent edit like any other simultaneous update.
Page freshness
Section titled “Page freshness”Page freshness is the second, lighter feature. It answers one question: is the page the user is looking at the same version that was last approved, or has it been edited since? It applies only to pages running a workflow with an approval transition, and surfaces through the Page Freshness macro embedded on the page. See the Page Freshness macro reference for placement and styling.
Aura compares the page’s current Confluence version number against the version recorded at the most recent approval event in the workflow history. If the current version is at or below the last approved version, the macro renders a green “This page is approved” banner. If the current version is higher, it renders a yellow “This page is not yet approved” warning with a link back to the last approved version. There is no time-based threshold and no “days since last edit” — staleness here means “edited after approval,” nothing more.
Freshness is computed live on every render. Nothing is stored, nothing is scheduled, and no email or reminder is tied to it. A page that has drifted past its last approved version stays flagged until it’s approved again (advancing the recorded approved version) or rolled back to a version at or below that one. Freshness has no per-state or per-workflow configuration; if the workflow has approvals, the macro works.
Because freshness is informational and expiration is the lever that moves pages, the two pair well. A common pattern gives a Published state both: an annual expiration that returns the page to review, and the Page Freshness macro at the top so editors see immediately when their changes have outpaced the last sign-off.