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 Inventory page toolbar shows the org-wide most-recent sync, as plain grey text beside the search box:

Resources    [Search resources...]   Synced 2 hours ago
─────────────────────────────────────────────────────────────────

The text does not change colour as it ages, so read the number yourself. Scans run every 6 hours, so anything under 6 hours is normal. Past 24 hours, the right response is to find out why scanning stopped, not to start another scan.

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                    The workflow's precondition step
                                    checks the resource before acting

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

There is no refresh button in the app. ZopNight scans an account as soon as it is connected, then every 6 hours. To start a scan sooner, call the API: POST /resources/refresh scans every connected account, or just one if you pass its cloudAccountId and provider in the request body.

T+0       A script or teammate calls POST /resources/refresh
T+1 sec   Discovery starts for the connected accounts
T+10 sec  Provider APIs respond with resource lists
T+60 sec  Per-resource metadata enrichment in progress
T+2 min   Scan completes; the Inventory page updates
T+2 min   View Permissions shows the fresh results

A scan usually takes a few minutes on a normal estate. While it runs, the Inventory page shows a “Discovering resources” banner, and the “Synced” timestamp updates when it finishes.

Status indication during refresh

While a refresh runs, the page checks its status every 3 seconds. There is no percentage bar; you see that it is running, and then a toast when it ends:

1. Idle                "Synced 23 minutes ago"
2. In progress         "Discovering resources" banner
3. Finished            "Sync complete: 3,920 resources discovered"
                       (or "Sync partially complete", "Sync failed",
                        or "Sync skipped" if one was already running)

The toast gives the total discovered, not what changed. To see what moved, re-apply your filters and compare.

Per-account refresh

For multi-account estates, scanning every account at once may be more than you need. Pass one account’s cloudAccountId and provider in the body of POST /resources/refresh and only that account is scanned. 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. Wait, or start a scan through the API.

2. The sync is failing. On the Cloud Accounts page, look for an account flagged as needing attention, open its View Permissions drawer, and read what is failing. 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

Very little, by design:

• How often discovery runs is fixed at 6 hours for every organisation, for cost reasons (more frequent runs increase cloud API costs for the customer’s account).
• Per-account refresh through the API lets you scan one account at a time.

The defaults are usually right. An API-triggered scan is the lever to reach for when you cannot wait.

2. Demo

A typical “I should refresh first” moment:

T+0       User opens Inventory page. Toolbar: "Synced 5 hours 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 triggers a scan through the API
T+90 sec  Refresh completes. Toast: "Sync complete: 3,920 resources discovered"
T+95 sec  User re-applies the filter: 30 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 Checks the count in the banner, then Stop selected
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 Inventory page:

1. Note the "Synced ..." timestamp in the toolbar.
2. Start a scan through the API (POST /resources/refresh).
3. Watch the "Discovering resources" banner. Note the duration.
4. When complete, read the completion toast.
5. Open Cloud Accounts page. Note the per-account sync timestamps.
6. If any account is flagged as needing attention, open View
   Permissions on it and read what is failing.
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, start a scan first.
The 60-90 seconds is cheap.

4. Knowledge check

Q1

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

A. Trigger a fresh scan first
B. Proceed; 5 hours is recent
C. Wait for the next scheduled sync
D. Use the cloud console

Q2

A specific GCP project’s resources have not updated for 31 hours, and its card on the Cloud Accounts page is flagged as needing attention. 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:

• Cloud Estate → Inventory toolbar: “Synced …” timestamp, plus a “Discovering resources” banner while a scan runs
• Cloud Accounts page: each account’s status and its View Permissions drawer. Per-account refresh is through the API (POST /resources/refresh with the account’s cloudAccountId and provider)

Automation does not refresh for you. An MCP or API start/stop acts on the resource as it is in the cloud, and the auto-remediation workflow starts with a precondition check on the resource before it acts. If you drive actions from a script or an assistant, ask for a refresh first when the stakes are high.

Module quiz

You have now completed all five lessons of M1.2. Take the module quiz: 10 questions, 80% to pass.

Related lessons

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

Glossary terms touched

Manual refresh · Discovery cron