Skip to content

PATTERN Cited by 1 source

Prioritised refresh by utilisation threshold

Pattern

When a multi-tenant SaaS computes per-tenant pre-computed reports asynchronously (see patterns/asynchronous-precomputed-report-batch-framework), recompute reports only for tenants whose utilisation has crossed a threshold relative to a hard limit (e.g. ≈70% of cap) — instead of refreshing every tenant on a fixed periodic schedule. Pair the strategy with two load-bearing UX commitments:

  • Show the last refresh timestamp on every report surface so admins always know when they're looking at stale data.
  • Provide an on-demand refresh action 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 pattern. Verbatim:

"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, keeping the system responsive where it matters most. To reduce the risk of acting on stale data: We show the last pre computation time for usage report. Admins can run ad-hoc reporting jobs for specific spaces/schemes whenever they want fresh data."

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

Problem

A pre-computation framework that refreshes every tenant's reports on a fixed schedule must scale its compute budget with tenants × entity_types × refresh_frequency. At multi-tenant SaaS scale this is "extremely expensive" — "an enormous volume of jobs which will result in huge load and stress on Jira APIs, Orchestrator, and the database, without clear customer benefit." The unconditional-refresh approach pays for tenants whose reports nobody reads at nearly the cost of paying for tenants whose reports are critical.

Solution

Refresh reports only for tenants whose utilisation has crossed a configurable threshold (e.g. 70% of a relevant limit), and accept acknowledged staleness for the rest:

function decide_refresh(scope_id) {
  utilisation = compute_utilisation_quickly(scope_id)
  if (utilisation >= REFRESH_THRESHOLD) {
    enqueue_full_refresh(scope_id)
  } else {
    // Acknowledged stale — staleness window unbounded
    // until utilisation crosses threshold or admin
    // explicitly requests refresh
  }
}

Pair this with the two UX commitments:

function render_report(scope_id) {
  report = read_persistent_report(scope_id)
  return {
    data: report.data,
    last_refresh_at: report.computed_at,   // staleness display
    on_demand_refresh_available: true,     // escape hatch
  }
}

Why a single threshold works

A single threshold (70% in Atlassian's case) divides tenants into two operationally meaningful classes:

  • Above threshold — likely to need the report soon (approaching a limit they can't cross). Worth paying the recompute cost.
  • Below threshold — unlikely to act on the report this cycle. Don't pay for them; surface staleness if they look anyway; offer the escape hatch.

The threshold itself is tunable. The 2026-05-14 post does not justify 70% with measurement; the implicit reasoning:

  • Refreshing only at the limit (100%) is too late — by then the tenant is already blocked.
  • Refreshing everyone (0%+) is the expensive baseline this pattern rejects.
  • 70% leaves headroom for the platform to schedule the refresh + the admin to take action before the limit hits.

Trade-offs

Property Prioritised refresh Refresh-everyone baseline
Compute cost O(tenants near threshold) O(all tenants)
Staleness for hot tenants Bounded (refresh on threshold crossing) Bounded
Staleness for cold tenants Unbounded until threshold or on-demand Bounded
First-touch latency for cold tenant report Fresh-on-demand (slow first time) Fresh always (fast)
Operational complexity Threshold + utilisation snapshot + UX commitments Just refresh
UX commitment Must show timestamp + on-demand button None

The hidden costs:

  • The staleness display obligation is non-negotiable. Skipping it turns the strategy into silent inconsistency — admins acting on stale data without knowing it.
  • The on-demand refresh escape hatch is non-negotiable. Without it, cold tenants have no way to get a fresh report when they actually need one.
  • Threshold tuning is operational work. Set too low, the cost saving is minimal. Set too high, hot tenants see stale data when they're approaching the limit.

Variations

  • Multi-threshold tiers — different refresh cadences at different utilisation bands (e.g. monthly at 0–50%, weekly at 50–70%, daily at 70%+).
  • Activity-aware refresh — refresh on writes / schema changes within a tenant, regardless of utilisation. Tighter coherence; bursty load.
  • Predictive refresh — refresh tenants whose utilisation is trending toward the threshold, not just currently above it. Advanced version of the same idea.
  • Tenant-tier refresh — refresh top-tier (paying or high-touch) tenants more often regardless of utilisation; refresh lower tiers only on threshold crossing. Aligns refresh budget with revenue-tier.

Adjacent patterns

Generalises beyond report-refresh

The pattern applies whenever:

  • There's a per-tenant precomputed materialisation.
  • The value of refreshing scales with tenant urgency.
  • A threshold metric is available cheaply enough to gate refresh decisions.

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

Seen in

Last updated · 542 distilled / 1,571 read