When discovery is stale: the refresh trigger

Outcome

By the end of this lesson, you will be able to recognize when the resource list is stale and trigger a manual refresh, and avoid acting on stale data.

1. Concept

The resource list is a photograph, not a live view.

Whether something is running or stopped, how it is tagged, what schedule it is on: all of that was true at the last scan. Acting on the list means acting on something between a few minutes and a few hours old.

Rather than hide that, ZopNight prints how old the picture is, so you can decide whether to act on it or refresh first.

The freshness signal

Every resource carries a “last seen” timestamp from the most recent successful discovery. The Resources page header shows the org-wide most-recent sync:

Resources    Last discovery: 2 hours ago        [Manual refresh ↻]
─────────────────────────────────────────────────────────────────

Under 6 hours, which is how often scans run, the time is grey. Past 6 hours it turns amber. Past 24 it turns red, and at that point the right response is to find out why scanning stopped, not to press refresh.

Each account has its own status on the Cloud Accounts page. When one account is failing and the rest are fine, only that account’s resources are out of date.

When to trust the list

ACTION                              FRESHNESS REQUIREMENT
─────────────────────────────────────────────────────────
Read-only browsing                  < 24 hours fine
Cost reporting                      6-24 hours typical
Building a new schedule             < 6 hours; refresh if older
Manual start/stop on prod           < 30 minutes; refresh first
Bulk action on many resources       < 30 minutes; refresh first
Auto-remediation                    Discovery runs immediately before
                                    each remediation attempt

For looking around, whatever you have is fine. Before anything with real reach, such as stopping a production cluster or acting on 50 resources at once, refresh first. It costs a minute and removes the chance that you are acting on something that has already changed.

The manual refresh trigger

The “Manual refresh ↻” button in the Resources page header triggers an immediate discovery cycle:

T+0       User clicks Manual refresh
T+1 sec   Discovery sync starts for all connected accounts
T+10 sec  Provider APIs respond with resource lists
T+60 sec  Per-resource metadata enrichment in progress
T+2 min   Sync completes; UI updates with new state
T+2 min   Permission Visibility drawer updated

A refresh takes 1 to 3 minutes on a normal estate. The button greys out and spins while it runs, and the timestamp updates when it finishes.

Status indication during refresh

The Resources page shows three states clearly:

1. Idle                "Last discovery: 23 minutes ago"
2. In progress         "Refreshing... 47% (1,840 / 3,920 resources)"
3. Recently completed  "Discovery complete: 12 resources changed"

The “12 resources changed” line tells you something moved. Click it and the list filters down to what appeared in that scan.

Per-account refresh

For multi-account estates, refreshing all accounts at once may be excessive. The Cloud Accounts page exposes per-account refresh:

Cloud Accounts
─────────────────────────────────────────────────────
prod-aws-us         Active     Last sync: 5h ago    [↻]
staging-aws-us      Active     Last sync: 5h ago    [↻]
prod-gcp            Active     Last sync: 5h ago    [↻]
prod-azure          Degraded   Last sync: 31h ago   [↻]  ← problem

A specific account can be refreshed individually. This is the right tool when only one cloud changed (e.g., the team just provisioned new GCP resources and wants those visible).

The “don’t act on stale data” rule

A principle to internalize:

Refresh before acting on resources that matter. The 60 seconds of refresh time is much cheaper than acting on a stale state.

Examples of when this rule pays off:

• A non-prod cluster was manually started by an engineer in the cloud console 20 minutes ago. ZopNight’s list still shows it as stopped. A bulk-start action against “all stopped non-prod” would skip this cluster (it’s already running) but would not break anything. Lower risk.
• A production database was stopped for an emergency maintenance 30 minutes ago. ZopNight’s list still shows it running. A scheduled action that “stop everything tagged stale-prod” might pick it up and try to stop something already stopped. That is harmless: stopping a stopped resource changes nothing, which is what idempotent means. But: in the time since the manual stop, somebody might have restarted the DB for production. Acting on the stale list could re-stop production.

The rule: refresh before high-stakes action. The 60 seconds buys correctness.

What causes staleness beyond 6 hours

Two scenarios:

1. The 6-hour cron has not yet fired. Normal. The next sync is on its way. Refresh manually or wait.

2. The sync is failing. Check Cloud Accounts page for any account showing “Degraded” or “Failed.” Click into the failing account, read the error in the Permission Visibility drawer or the sync status panel. Most failures resolve with the same fixes from M1.1 L4 (a missing IAM permission, a revoked credential, an expired SAML federation).

What the user can configure

A few preferences are available:

• How often discovery runs is fixed at 6 hours, for cost reasons (more frequent runs increase cloud API costs for the customer’s account). Premium plans can ask for it to run more often.
• Per-account refresh lets the user trigger one account at a time
• Notification on completed refresh can be enabled per organization

The defaults are usually right. The Manual refresh trigger is the lever the user touches most.

2. Demo

A typical “I should refresh first” moment:

T+0       User opens Resources page. Header: "Last discovery: 5h ago"
T+5 sec   User filters to "non-prod, running": 38 resources match
T+10 sec  User intends to bulk-stop 25 of them for the weekend

PAUSE: user notices the 5h-ago timestamp. Some of these may already
be stopped or may have changed tags.

T+15 sec  User clicks Manual refresh
T+90 sec  Refresh completes. Toast: "12 resources changed since last sync"
T+95 sec  User re-applies the filter: 32 resources match now
          (6 were already stopped by an automation; 2 had their tags changed
          and no longer match "non-prod")
T+100 sec User selects the 25 still-running, still-correctly-tagged resources
T+110 sec Bulk stop with confirmation
T+170 sec All 25 stopped successfully

The 90-second refresh saved the team from accidentally trying to stop 6 already-stopped resources (no harm, but noise) and from stopping 2 resources whose tags had changed and shouldn’t have been in scope.

3. Hands-on (6 min)

On the Resources page:

1. Note the "Last discovery" timestamp in the header.
2. Click Manual refresh.
3. Observe the progress indicator. Note the duration.
4. When complete, read the change summary toast (if any).
5. Open Cloud Accounts page. Note the per-account sync timestamps.
6. If any account shows "Degraded," click into it and read the
   sync status panel for the error message.
7. If all accounts are healthy, you have confidence the resource
   list reflects reality.

THEN: take the rule home. Before any bulk action on >10 resources
or any manual action on production, hit Manual refresh first.
The 60-90 seconds is cheap.

4. Knowledge check

Q1

A team is about to bulk-stop 47 production-adjacent resources. The Last Discovery timestamp shows “5 hours ago.” Best practice:

A. Click Manual refresh first
B. Proceed; 5 hours is recent
C. Wait for the next scheduled sync
D. Use the cloud console

Q2

A specific GCP project shows “Last sync: 31 hours ago” and “Degraded” status. The expected diagnosis path:

A. ZopNight itself is simply broken somewhere upstream
B. Wait three days
C. Open the GCP account from the Cloud Accounts page
D. Replace ZopNight

Q3

“Don’t act on stale data” most directly motivates:

A. Always wait for a full 24 hours before taking any action on it of any kind or description
B. Disable schedules
C. Manual everything
D. Refresh before high-stakes actions (bulk operations, production resources, anything irreversible)

5. Apply

The freshness signal is in two places:

• Resources page header: Last Discovery timestamp + Manual refresh button
• Cloud Accounts page: per-account sync status and per-account refresh

For automation-driven workflows (MCP, API), refresh is implicit before each remediation attempt; the auto-remediation pipeline always runs a discovery sync immediately before acting on the resource, so it cannot act on stale state by design.

Module quiz

You have now completed all five lessons of M1.2. The module quiz (10 questions, 80% pass) is on the Operator certification page.

Related lessons

• M1.3: Build your first schedule (next module)
• M1.1 L4: Permission Visibility

Glossary terms touched

Manual refresh · Last Discovery timestamp · Stale data · Per-account sync · Degraded status