Outcome
By the end of this lesson, you will be able to recognize when a missing savings figure is caused by missing pricing data, explain the three causes of pricing gaps, and know when to raise a support request.
| Prerequisites | M2.1.L4 (pricing model) · M2.2.L1 |
| Time | 9 minutes |
1. Concept
Some rules cannot state a saving without knowing what the resource costs per hour.
Occasionally that price is missing: a resource type, a region or a machine size the pricing data does not cover yet. The rule then has nothing honest to report.
ZopNight’s answer is concrete-or-abstain. It does not show you a guessed number or a $0 card. The cost recommendation simply does not appear until the rate exists. Behind the scenes, the gap is recorded so ZopDev staff can see it.
WHAT HAPPENS WHEN A PRICE IS MISSING:
Cost rule evaluates the resource → no usable price for its type → no recommendation is shown (no guess, no $0 card) → the gap is logged on ZopDev's side → next pricing sync adds the rate → the next evaluation shows the recommendationWhich findings are affected
Only cost-driven findings need a price: idle, rightsizing, schedule and discount. Two kinds of finding are not affected:
NOT AFFECTED BY A PRICING GAP: Orphan findings an unattached disk is worth cleaning up whether or not it can be priced Posture findings compliance, security, reliability, governance and performance keep their rule-declared severity; no dollar figure is involvedSo a pricing gap never hides a security or compliance problem. It only delays a savings figure.
What you see as a customer
CASE A: the resource never had a recommendation Recommendations list: nothing for that resource yet Resource still appears in inventory and cost views Once the rate lands: the recommendation shows up on the next evaluation, with its savings figure
CASE B: a recommendation was open, then its price went missing The finding is closed with the reason "No price data" Its history explains: the saving could not be verified, so it was closed rather than shown as an unverified number Once the rate is back: the finding can be raised againThere is no “pending pricing data” card and nothing for you to apply, dismiss or replay. Your job is only to notice when a gap does not go away.
Three causes of pricing gaps
CAUSE 1: NEW SKU Cloud provider releases a new instance type or storage class Example: a new instance family launches mid-month Pricing sync runs weekly; it hasn't fetched the rate yet TYPICAL DURATION: up to about a week; clears on its own
CAUSE 2: NEW REGION You start running resources in a region you did not use before The next pricing sync picks up its rates TYPICAL DURATION: up to about a week; clears on its own
CAUSE 3: RARE COMBINATION Unusual region + SKU + OS combination not in the public price list Example: a storage redundancy option in a less-common region The gap is structural; it won't clear on its own TYPICAL DURATION: until ZopDev engineering adds coverageCauses 1 and 2 are the common ones and need nothing from you. Cause 3 is where a support request helps.
What ZopDev does behind the scenes
ZopDev keeps an internal list of pricing gaps (engineers call it a dead-letter queue, or DLQ). For built-in rules it has one entry per rule and resource type, with first and last seen times and a count. Only ZopDev staff can open it. Staff review it, re-run evaluation once rates land, and send structural gaps to engineering.
THE INTERNAL LIST TRACKS: Rule that wanted a price Resource type, provider and category When the gap was first and last seen How many times it has occurredBecause a built-in rule’s gap rolls up per resource type, one support request about a type helps every account that runs it.
When to raise a support request
RAISE A REQUEST WHEN: A resource type you run in volume never shows a savings figure, while similar types do The gap has lasted longer than two weekly pricing syncs Findings closed with "No price data" keep recurring
INCLUDE: Provider, resource type or instance size, region How many resources you run of that type When you first noticed (a date) Any finding closed with "No price data", if you have one
DON'T RAISE A REQUEST WHEN: The type launched in the last week (cause 1) You only just started using the region (cause 2) The resource has only orphan or posture findingsA precise request is quick to act on; “we see fewer savings than expected” is not.
2. Demo
A platform team notices a gap during their monthly recommendation review:
MONTHLY REVIEW (Q2 2026):
T+0 Open Recommendations; filter to Rightsizing Compute rightsizing findings look normal for most instance families
T+2 min Notice: 40 VMs of a newly launched instance family show no rightsizing or idle findings at all Several sit near 3% CPU in the Metrics drawer Family launched 5 days ago Decision: likely cause 1 (new SKU); wait one week
T+4 min Notice: 120 storage accounts using one redundancy option in a less-common region No savings figure has ever appeared for them Same option in other regions shows findings Decision: likely cause 3 (rare combination)
T+6 min Check history on one storage account An older finding closed with "No price data" Confirms the gap is pricing, not the estate
T+8 min Raise a support request: Provider: Azure Type: storage account, that redundancy option Region: the less-common one Count: 120 resources First noticed: this review Evidence: one finding closed with "No price data"
T+1 week Re-check: New instance family: rightsizing findings now present (weekly sync added the rate) Storage accounts: still no figure; support confirms engineering is adding coverage
T+1 month Re-check at next review: Storage accounts: findings now presentThe pattern: wait out the new SKU, report the structural gap once with precise details, then confirm at the next review.
3. Hands-on (5 min)
Pricing-gap check on your estate:
□ STEP 1: Open Recommendations; filter to one cost category (rightsizing or idle) Category: __________
□ STEP 2: List resource types you run in volume Type 1: __________ Count: _____ Findings? □ Yes □ No Type 2: __________ Count: _____ Findings? □ Yes □ No Type 3: __________ Count: _____ Findings? □ Yes □ No
□ STEP 3: For each type with no findings Launched or adopted in the last week? □ Yes □ No New region for you? □ Yes □ No Metrics suggest waste anyway? □ Yes □ No
□ STEP 4: Look for "No price data" closures Finding history checked for: __________ Found any? □ Yes □ No
□ STEP 5: Decide Wait (cause 1 or 2): _____ types Raise a support request (likely cause 3): _____ types Details ready: provider, type, region, count, date □A quick pass shows whether any part of your estate is quietly missing savings figures.
4. Knowledge check
Q1
A cost rule would fire on your new VM, but ZopNight has no price for its instance type yet. What do you see?
A. No recommendation for it yet; one appears after the rate lands
B. A card reading “pending pricing data” with Apply and Dismiss buttons
C. A recommendation with a $0 savings figure
D. An error that stops recommendations for the whole account that day
Show answer
Correct: A. Concrete-or-abstain: a cost rule that cannot price its finding shows nothing rather than a guess. The gap is logged for ZopDev staff, and the recommendation appears on the first evaluation after the rate lands.
Q2
A new AWS instance type lands. ZopNight’s recommendation engine:
A. Recognizes it immediately, since the rate card is fetched live on every single run
B. Cannot handle new types
C. Shows no cost findings for it until the next weekly pricing sync adds its rates
D. Requires manual coding
Show answer
Correct: C. Pricing sync runs weekly. Until it adds the rate, cost rules stay silent for that type; afterwards the next evaluation shows the recommendations. No action is needed from you.
Q3
For a month, 120 storage accounts of one rare type in one region have never shown a savings figure. Best move:
A. Keep waiting, since every pricing gap clears with the next weekly sync
B. Open the pricing-gap queue in Settings and replay the stuck entries
C. Assume these resources are already well optimized and move on
D. Raise a support request naming the type, region and resource count
Show answer
Correct: D. A gap that outlasts several weekly syncs is structural, so it will not clear on its own. The pricing-gap queue is internal to ZopDev staff; a precise support request is how it reaches engineering.
5. Apply
You will not see pricing gaps as cards. Watch for resource types that never show a savings figure, and for findings closed with “No price data”.
For your team: add a pricing-gap check to the monthly recommendation review. Wait out new SKUs and regions; raise a support request for any gap that lasts beyond two weekly syncs.