Skip to content

CONCEPT Cited by 1 source

Utilisation-prioritised refresh strategy

Definition

Utilisation-prioritised refresh is the operational discipline of recomputing pre-computed reports for multi-tenant SaaS only when a tenant (or scope) crosses a utilisation threshold relative to a hard limit, rather than refreshing every tenant on a fixed periodic schedule. The strategy explicitly accepts acknowledged staleness for low-utilisation tenants in exchange for compute-budget preservation, and pairs the staleness with two load-bearing UX commitments:

  • Display the last refresh timestamp on every report surface.
  • Provide an on-demand refresh escape hatch so any admin can request a fresh recomputation for a specific scope.

The 2026-05-14 Atlassian post is the first canonical wiki home for this concept. Verbatim framing:

"Recomputing them for every space, on a fixed schedule, is extremely expensive at Jira scale. Refreshing every space regularly would generate an enormous volume of jobs which will result in huge load and stress on Jira APIs, Orchestrator, and the database, without clear customer benefit. We deliberately optimise for smart, prioritised refreshes by recomputing reports only for spaces nearing limits (≈70% utilisation). Some low-utilisation spaces may see older data, but this lets us focus resources on spaces most likely to benefit from optimisation."

(Source: sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat)

The problem this solves

Pre-computed reports lose value as tenant data evolves — classic cache-coherence / materialised-view-staleness territory. Two extreme strategies bracket the design space:

  • Refresh everyone every cycle — bounded staleness, but compute cost scales linearly with tenant count regardless of who is actually near a limit. At Jira scale this is "extremely expensive."
  • Refresh nobody, only on-demand — minimum compute, but every admin pays the cold-start latency on first access, and Site Optimiser dashboards become unable to surface "who's nearing a limit" without user interaction.

Utilisation-prioritised refresh is the principled middle point: refresh those who are likely to act on the report (tenants near limits where remediation is valuable); acknowledge staleness for the rest; expose both the staleness state and the refresh escape hatch in the UI.

Mechanism

A pre-computation framework implementing this strategy typically:

  1. Maintains a per-scope utilisation snapshot — lightweight to compute, stored as (scope_id, metric_name, current_value, limit_value, ratio, last_full_refresh_at).
  2. Schedules full report refresh selectively — only when ratio >= threshold (e.g. 0.70 in Atlassian's case) or when the scope was recently mutated above some activity floor.
  3. Surfaces the staleness state in the UI — "last pre-computation time for usage report" visible alongside every report surface.
  4. Exposes an ad-hoc refresh action — admins can trigger a full recomputation for any specific scope regardless of the current utilisation ratio.

Why ≈70%, not the limit?

The 70% threshold is a chosen operating point — the 2026-05-14 post does not justify it with a measurement, but the implicit reasoning is operationally sensible:

  • Refreshing only at 100% (the limit) is too late. By the time a tenant has hit a limit, configuration changes are blocked and the admin needs the report immediately, with the lowest acceptable staleness.
  • Refreshing at every percentage is too eager. Most tenants will spend most of their lives in the 0–60% utilisation band where staleness has near-zero customer cost.
  • 70% leaves a lead-time gap for the platform to accumulate refresh jobs, the report to populate Site Optimiser, and the admin to take action before the limit is reached.

The threshold is itself a knob — could be tuned per metric / per tenant tier / per cost regime — but the 2026-05-14 post documents it as a single operational constant.

Trade-offs

Property Utilisation-prioritised refresh
Compute cost O(tenants near limit), not O(all tenants)
Staleness Acknowledged for low-utilisation tenants
First-touch latency Fast (report is pre-computed for the relevant tenants)
Cold-tenant first-touch May see older data; on-demand refresh available
Operational complexity Adds threshold-tuning + staleness-display obligation
UX commitment Must show last-refresh timestamp + on-demand button

The hidden tax is the UX commitment: skipping the staleness display turns the strategy into silent inconsistency. The on-demand refresh escape hatch is the load-bearing UX promise that makes acknowledged staleness acceptable.

Adjacent strategies

  • Time-bounded refresh — refresh every N hours unconditionally. Simpler, but doesn't scale.
  • Activity-triggered refresh — refresh on writes / schema changes. Tighter coherence, but bursty load and doesn't help tenants near limits whose data hasn't changed.
  • Pull-only / lazy refresh — refresh on first read after staleness threshold. Lower amortised cost, but worst-case latency falls on the user.
  • Predictive refresh — refresh tenants whose utilisation is trending toward the limit, not just currently above the threshold. Advanced version of the same idea; not disclosed by Atlassian.

Generalises beyond configuration-bloat reports

The strategy applies to any situation where:

  • There's a per-tenant precomputed report or materialisation.
  • The value of refreshing scales with tenant urgency (a tenant near a limit needs recent data; a tenant far from the limit doesn't).
  • A utilisation or threshold metric is available cheaply enough to gate refresh decisions on.

Other natural candidates: usage-quota dashboards, billing-tier upgrade-prompts, security-posture scoring, license-utilisation reports.

Seen in

  • sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat (2026-05-14, Atlassian) — first canonical wiki home. Names the strategy with operational rationale (refreshing every space "extremely expensive at Jira scale"), the ≈70% utilisation threshold, the staleness UX commitments ("show last pre-computation time" + "ad-hoc reporting jobs"), and the canonical exception case ("low-utilisation spaces may see older data").
Last updated · 542 distilled / 1,571 read