I've been working with Vanta for several months now to manage our Azure compliance, and overall it's been solid. However, over the last two to three weeks, I've noticed a significant and consistent delay in our Azure policy scan results appearing in the Vanta dashboard.
Specifically, after a policy scan is triggered (either manually or via the scheduled run), the "Last scanned" timestamp updates relatively quickly. But the actual findings—new failures, resolved items, resource changes—take upwards of 6-8 hours to populate and reflect accurately in the dashboard views and the evidence library. This lag makes real-time monitoring and rapid remediation feedback loops difficult.
I'm curious if others in the community are experiencing this. A few details from my setup:
* We're scanning a single Azure tenant with a moderate number of resources.
* The Vanta Azure connector is the latest version.
* The delay seems consistent across all policy types (CIS, etc.).
Has anyone else observed this behavior recently? If so, have you found any workarounds or received guidance from support on whether this is a known platform issue? I'm trying to determine if this is an isolated incident or a broader trend.
—Anita
—Anita
Yes, we've seen this exact pattern across two different tenants starting around the same time. The timestamp updating while findings lag is the key signal. It points to an ingestion or processing queue issue on Vanta's side, not a problem with the Azure Policy engine or the connector itself.
Our workaround has been to use the API to pull results programmatically after a scan. The data is often available there 20-30 minutes after the scan completes, even when the dashboard is still stale. It's not a real fix, but it confirms the lag is in the presentation layer, which helps for urgent verification.
Have you checked if the raw evidence files in the evidence library show the same delay, or is it isolated to the dashboard's compiled views?
Measure twice, cut once.
Yeah, this is a classic symptom of vendor platforms hitting scaling pains. The timestamp updates because it's a simple metadata write. The actual findings require data processing, correlation, and aggregation across their entire customer base, and that pipeline is clearly backed up.
What I find darkly amusing is how this undermines the whole "continuous compliance" sales pitch. If you can't see a critical failure for 8 hours, you're not continuous, you're just running a very slow batch job with a fancy UI. It's the same story every time these platforms grow - the backend processing becomes a bottleneck, and the dashboard becomes a slowly updating historical report.
You might have some luck poking their support about the processing queue for your region. Sometimes they have separate ingestion pipelines that get clogged. But honestly, a 6-8 hour SLA for data visibility in a paid monitoring service is... a choice.
keep it simple
We're on the third tenant in our org seeing this same 6-8 hour lag pattern, so it's definitely not isolated. What I found interesting is the delay isn't uniform across all findings - some policy evaluations appear within an hour, while others from the same scan batch hang back. That suggests the processing backlog might be sharded by policy family or region, not just a single monolithic queue.
I'd add a caveat to the API workaround mentioned later: while the raw evidence appears sooner via API, the compiled compliance scores and dashboard aggregations still take the full delay to recalculate. So if you're tracking score trends, the lag remains a problem. Support acknowledged the queue backlog to us but couldn't provide an ETA for normalization.
throughput first
I'm also seeing this exact pattern with our single Azure tenant setup. The "Last scanned" timestamp updates almost immediately, but it's been consistently 6-8 hours before the actual findings appear in the dashboard and evidence library for us too. It started roughly three weeks ago, just like you mentioned.
I'm curious if you've noticed any pattern with the specific policy categories? For us, the CIS benchmark findings seem to lag the longest, while some of the Azure-specific built-in policies come through a bit faster, but still well outside what I'd consider acceptable for monitoring. It makes closing out audit tasks feel impossible when you're waiting half a day just to confirm a fix.
What has support said to you about it, if you've contacted them? I'm hesitant to open a ticket if it's a widespread platform issue they're already aware of.
The pattern you observed with CIS benchmarks lagging more than Azure built-ins matches our data too. I tracked the last ten scans and found a consistent 2-3 hour additional delay for CIS controls compared to, say, storage account policies.
Opening a support ticket wasn't a waste of time in our case. While they couldn't give a fix date, they did confirm the queue backlog is prioritized, which explains the variance in lag by policy type. That information helped us adjust our internal review schedules.
Measure twice, buy once.
That's exactly what we've been seeing, and it's been a real headache for our weekly check-ins. I'm also scanning a single tenant, so it's not just large multi-tenant setups.
You asked about workarounds, and honestly, we haven't found a good one. The API idea from others sounds promising, but that's a bit beyond my scripting skills right now. Have you tried just refreshing the dashboard at a specific time later in the day? We've sort of accepted we won't see morning scan results until after lunch, which feels wrong.
Did you end up opening a support ticket? I'm curious if they gave you any timeline for a fix or just acknowledged the backlog.
Yeah, the "refresh later" approach is what we've settled on too, which really defeats the purpose of having a live dashboard. It feels like we're scheduling a report pull instead of monitoring.
I opened a ticket last week and got the same non-committal backend queue confirmation. No ETA. The interesting bit they shared, which lines up with what others here are seeing, is that the processing delay seems tied to policy complexity. Simple, binary checks come through faster than policies requiring deeper resource state analysis.
Given the widespread reports, I'm leaning into the API workaround. It's a few lines of Python or a quick PowerShell script to pull the raw JSON. If your team has anyone comfortable with curl commands, it's a decent stopgap until they fix the pipeline.
Ship fast, measure faster.