Build Resource Graph Explorer query configs with KQL queries for orphaned resources, compliance reports, and inventory.
Build Resource Graph Explorer query configs with KQL queries for orphaned resources, compliance reports, and cross-subscription inventory.
Required Fields
queryNamequeriesqueries[0].namequeries[0].kqlOutput will appear here...The tool validates that queryName, queries, and the first query's name/kql resolve, then assembles the combined query set plus optional scheduled export configuration into the shape Resource Graph Explorer and its export feature expect; it doesn't execute the KQL or validate it against Resource Graph's actual supported syntax subset, that's only confirmed when the query is run against a live Resource Graph endpoint.
Build Azure Resource Graph KQL queries operating over the resources table (a cached, cross-subscription snapshot of resource metadata, refreshed periodically rather than a live query against every resource), well suited for exactly the kind of orphaned-resource and cross-subscription inventory reports in the example (unattached disks, unused public IPs, orphaned NICs). Resource Graph's KQL is a meaningfully restricted dialect of the same language used in Log Analytics/ADX, several operators and functions available in those contexts simply aren't supported against the resources table, and the query results reflect Resource Graph's cache freshness (typically within minutes, not instantaneous), both worth knowing before assuming a query pattern that works in Log Analytics will translate directly.
Don't assume every Log Analytics or ADX KQL pattern works unchanged against Resource Graph's resources table, its supported KQL subset is more restricted, test queries directly against Resource Graph rather than assuming portability from a different KQL context.
Remember Resource Graph reflects a periodically-refreshed cache, not live resource state, fine for governance and inventory reporting, not appropriate as the basis for a decision requiring guaranteed real-time accuracy.
Scheduled exports turn one-off manual queries into an ongoing, hands-off reporting habit, worth setting up for any query (like the orphaned-resource ones in this example) that's genuinely valuable to check regularly rather than only when someone remembers to run it.
A cached snapshot, refreshed periodically (typically within minutes of an actual resource change, not instantaneous), Resource Graph trades a small amount of freshness for the ability to query across potentially thousands of resources and many subscriptions quickly, without the latency of querying each resource provider live. For most inventory and governance use cases this lag is inconsequential, but don't rely on Resource Graph results for a decision requiring absolutely real-time resource state.
No, Resource Graph supports a meaningfully restricted subset of KQL compared to Log Analytics or Azure Data Explorer, certain operators, join types, and functions available in those richer KQL contexts aren't supported when querying the resources table. If a query pattern that works in Log Analytics fails against Resource Graph, check the specific supported KQL subset rather than assuming it's a syntax typo.
It runs the query fresh at the scheduled time (against Resource Graph's then-current cached snapshot, which is itself continuously refreshed), so a weekly Monday 8am export reflects resource state as of Resource Graph's cache at that time, not a stale result from whenever the export was originally configured.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.