In this page
Refresh content statuses job
What does it do?
This job refreshes the status of all contents in your Confluence.
Knowing the most current status of the contents is key for efficient content lifecycle management, but to have near real-time status values, this job should run continuously. The problem is that because the job uses a lot of resources (network traffic, Confluence REST API calls, etc.), running this frequently would overload the infrastructure and would be costly.
The app implements the following status-refresh strategy as a practical trade-off:
- The scheduler runs this job periodically to refresh the status of all contents.
- Plus, users trigger refreshing the status of a single content by opening its content status indicator.
- (Plus, a new event handler which refreshes the content status when "certain things happen" is coming soon!)
Overall, the "mass refreshes" by the job and the "micro refreshes" by the users maintain the content statuses with low latency.
How it works
Conceptually, the job runs either across all spaces (site scope) or on a single specific space (space scope).
The actions performed by the job depend on whether the space is currently included or excluded. (Note that in space scope, the selected space is never excluded, since you can’t manually start a job on an excluded space – the app simply hides the controls in that case.)
- For included spaces:
- It takes the content status scheme used by the space.
- It processes all contents in the space and sets its new status:
-
It tests the CQL queries of the statuses in the scheme from top to bottom:
- If the status' direct CQL matches the content, then this status will be set. (direct status)
- Or if the status' ancestor CQL matches the ancestors of the content, then this status will be set. (inherited status)
- If there is no match, the default status will be set.
-
It tests the CQL queries of the statuses in the scheme from top to bottom:
- For excluded spaces:
- If a status was previously calculated, it will be cleared.
- The content itself is marked, so other app features (such as reporting) will no longer include it.
Once the job has completed, the status of all contents within scope will be refreshed. After Confluence updates its internal indexes, CQL expressions should consistently return up-to-date status information.
Scheduled runs
This job runs in site scope, every 6 hours for paid customers. During the evaluation period, it runs once per day.
The job doesn’t start exactly at the top of the hour. Instead, it starts at a fixed, randomly assigned minute between the 10th and 35th minute of each hour – the exact minute is specific to your cloud instance. This helps distribute the overall load on the Confluence Cloud APIs more evenly.
Manual runs
Beware: Running this job can be very time-consuming for large spaces!
You should run this job manually only if:
-
If the content status overview displays a warning telling that your content statuses are invalid.
It can happen if:
- If you modify a content status scheme, it will invalidate the statuses in all spaces that use this scheme.
- If you modify a content status, it will invalidate the statuses in all spaces that use a scheme which includes this status.
- If you included a previously excluded space, for which the job has not yet run recently.
- If you need the current statuses immediately (e.g. because you are compiling a content status report and want to work with the most accurate data).
- If the Midori support team asks for that.
Note that if you don't run the job despite the warning, that's no problem at all. It will catch up at the next scheduled execution.
Supported metrics
- Spaces processed
- Spaces total
- Content statuses cleared
- Content statuses refreshed
To understand what each metric means, please refer to the documentation on the job audit log.
Questions?
Ask us any time.