{{ summaryHeading }}
{{ coverageDisplay }}
{{ summaryLine }}
{{ badge.label }}
Cloud tag coverage inputs
Used in exports and JSON so the tag gap evidence can be handed to the owning team.
Example: Owner, Environment=prod|stage|dev, CostCenter, DataClass.
Paste a cloud inventory export. Tags can be Owner=team;Environment=prod or a small JSON object.
{{ sourceHint }}
Use your governance target for all required tag keys across the audited resources.
%
Choose strict for policy enforcement evidence; use case-insensitive for early discovery exports.
Allowed values in Required tags are always enforced when supplied.
Leave blank for a full audit. Example: snapshot-copy, vm-extension.
Leave blank for neutral scoring, or enter keys such as Owner, CostCenter.
Measure Value Evidence Copy
{{ row.measure }} {{ row.value }} {{ row.evidence }}
Resource Type Provider Region Covered Missing or invalid tags Status Copy
{{ row.resourceId }} {{ row.type }} {{ row.provider }} {{ row.region }} {{ row.coveredDisplay }} {{ row.gapDisplay }} {{ row.status }}
No resource rows are available.
Required tag Coverage Missing key Invalid value Affected resources Next action Copy
{{ row.tagKey }} {{ row.coverageDisplay }} {{ row.missingCount }} {{ row.invalidCount }} {{ row.examplesDisplay }} {{ row.action }}
No required tags are available.

          
Customize
Advanced
:

Introduction

Cloud tag coverage measures how many resources carry the metadata keys that a team expects to see on every governed asset. Those keys usually answer simple but important questions: who owns the resource, which environment it belongs to, which cost center should pay for it, and whether the data or workload needs special handling.

The percentage matters because untagged resources create real operational gaps. A production volume without an owner can slow incident response. A service without a cost center can land in an unallocated spend report. A storage object without a data classification can make retention or review work harder than it needs to be.

Cloud tag coverage audit flow from resource inventory through required tags, value rules, coverage checking, and remediation handoff.

Coverage should be read as an audit signal, not as a guarantee that the metadata is complete in every source system. Cloud providers differ in tag support, inheritance, casing, limits, and billing export behavior. Some child resources cannot be tagged directly, and some billing records can appear before tag changes reach reports. That is why coverage checks are most useful when they are tied to a defined scope, a stable tag dictionary, and a clear remediation owner.

A strong tag audit separates two mistakes that often get mixed together. A missing key means the resource does not carry the required label at all. An invalid value means the key exists, but the value is blank when a value is required or does not match the allowed vocabulary. Both gaps matter, but they usually need different cleanup work.

Technical Details:

Tag coverage is a resource-level completeness measure. Each checked resource is compared against a set of required tag keys. A resource counts as complete only when every required tag passes the current key and value rules. The audit percentage is therefore stricter than a per-tag average, because one missing ownership key can keep an otherwise well-tagged resource out of the complete count.

Key matching matters because cloud exports are not always consistent. Strict matching treats Environment and environment as different keys, which is useful for policy evidence when the standard spelling must be enforced. Case-insensitive matching is better for early discovery because it shows intent across mixed exports before a cleanup campaign standardizes casing.

Value checks add another distinction. Key-only coverage accepts a present key even when its value is blank. Non-empty coverage requires a value for each required key, and allowed-value rules narrow that further when a tag is written as Environment=prod|stage|dev. In that case, a resource with Environment=test is counted as invalid rather than missing.

Formula Core

Resource coverage uses complete resources divided by checked resources after ignored resource types are removed.

Coverage = Complete resources Checked resources × 100
Cloud tag coverage terms
Term Meaning Important boundary
Checked resources Parsed inventory rows after excluded resource types are removed. If exclusions are too broad, the percentage can look better than the real estate deserves.
Complete resources Rows where every required tag has passed the key, value, and allowed-value checks. One failed required tag keeps the whole resource out of this count.
Tag debt Missing required keys plus invalid or blank values across the checked resources. This is a slot count, not a resource count, so one resource can contribute several issues.
Target met Coverage is greater than or equal to the configured percentage target. The target gate does not confirm that tag values are useful beyond the declared rules.

Rule Core

The audit reads each row as a cloud resource with optional type, provider, region, and tag evidence. Headered CSV is preferred, but common aliases such as resource ID, resource type, cloud, platform, labels, and tag set are recognized. Tag text can be parsed as semicolon-separated or pipe-separated key/value pairs, and a small JSON object can be used for the tag column.

Tag coverage rule outcomes
Condition Outcome Remediation meaning
Required key is absent after the selected key match rule is applied. Missing key. Backfill the key on the affected resource or fix the export if the key was lost during collection.
Required key is present, value rule is non-empty, and the value is blank. Invalid value. Add a real value instead of counting the empty key as governed metadata.
Required key includes allowed values and the resource value is outside that list. Invalid value. Map the value back to the controlled vocabulary, such as prod, stage, or dev.
Resource type matches the ignored type list. Removed from checked resources. Use this only for technical child resources that cannot be tagged directly.
A required key is listed as a priority tag. Sorted earlier in the remediation queue. Focuses cleanup on high-value keys such as ownership or cost allocation before lower-impact gaps.

The calculation is deterministic for the same inventory text, required tag list, key matching mode, value rule, ignored resource types, priority tags, and target percentage. Comparing two runs is meaningful only when those assumptions stay fixed or when the changed assumption is the point of the comparison.

Everyday Use & Decision Guide:

Start with the same inventory slice you would hand to the team that owns cleanup: one account, subscription, project, resource group, or reporting export. Put that label in Cloud scope so copied rows, JSON, and downloaded files keep their context after they leave the page.

Use Required tags for keys that must be present across the audited scope. For ordinary discovery, enter keys such as Owner, Environment, and CostCenter. Add allowed values only when the vocabulary is already agreed, for example Environment=prod|stage|dev. A half-defined allowed-value list can create false cleanup work.

Choose Strict tag keys when the audit is policy evidence. Choose Case-insensitive tag keys when the first job is to find rough coverage across exports that mix Environment, environment, and similar casing. If the two modes produce very different results, standardizing tag key spelling is part of the remediation.

  • Keep Require non-empty values for governance tags that drive cost, ownership, or environment reports.
  • Use Only require the key when a provider export represents key presence separately from value quality, or when blank values are acceptable for the current review.
  • Set Coverage target to the governance bar you actually use, such as 95 percent for a first pass or 100 percent for critical shared infrastructure.
  • Use Ignored resource types sparingly. Excluding child resources can make sense, but excluding messy resource classes can hide work that still needs an owner.
  • Put Owner, CostCenter, or other high-value keys in Priority tags when the cleanup queue should show them before lower-impact gaps.

Read Coverage Snapshot first, then open Resource Gap Ledger to see which resources failed and why. Tag Remediation Queue is the best handoff view when you want to assign cleanup by required key, affected examples, and next action.

Step-by-Step Guide:

One pass should leave you with a target status, the largest tag gap, and a cleanup queue that can be copied into a ticket or review note.

  1. Enter an account, subscription, project, or export label in Cloud scope. Confirm the same scope name appears in the snapshot evidence and exported filenames.
  2. Add the policy keys in Required tags. Use comma-separated or line-separated keys, and add allowed values with the Key=value1|value2 pattern when the vocabulary is controlled.
  3. Paste CSV rows into Resource inventory CSV, choose Browse, or drop a .csv, .txt, or .tsv file onto the input area. If the file error says the file is over 1 MiB, split the export and rerun a smaller scope.
  4. Click Normalize when the parsed rows should be rewritten into the standard resource_id,type,provider,region,tags shape. If Parser warnings appears in Coverage Snapshot, fix the header or tag column before relying on the result.
  5. Set Coverage target, Key matching, and Value rule. Watch the summary badge change between target met and coverage gap as the gate and rules change.
  6. Open Advanced only when you need to exclude technical child resources with Ignored resource types or move high-value keys earlier with Priority tags.
  7. Review Coverage Snapshot for Resource coverage, Tag debt, Largest gap, key matching, value rule, ignored resources, and parser warnings.
  8. Open Resource Gap Ledger for row-level missing or invalid tags, then use Tag Remediation Queue to assign fixes by required tag and affected examples.
  9. Use Required Tag Coverage or JSON after the tables match the audit scope, not before. The chart and JSON are handoff views of the same parsed result.

Interpreting Results:

Resource coverage is the main pass/fail signal. It shows the share of checked resources that satisfy every required tag rule. A result of 90 percent against a 95 percent target means the scope needs remediation even if most individual tags look healthy.

Tag debt explains the size of the cleanup. A tag debt of 12 can mean 12 resources each have one gap, or three resources each have four gaps. Use Resource Gap Ledger when resource ownership matters and Tag Remediation Queue when the cleanup owner works by tag key.

Cloud tag coverage result cues
Visible cue Best first reading What to verify next
coverage gap The percentage is below the configured coverage target. Confirm the target and exclusions before assigning cleanup work.
Largest gap One required tag has the most missing or invalid slots. Check whether that key is missing from a specific resource type or owner group.
Invalid value count is high Keys exist, but blanks or vocabulary mismatches are common. Review the allowed values and check for spelling, casing, and legacy values.
Ignored resources is populated Some rows were excluded before the coverage percentage was calculated. Confirm each ignored type cannot or should not carry the required tags.
Parser warnings appears Some input evidence may not have been read as intended. Fix the header, tag column, or missing resource IDs before using the result in a formal handoff.

Do not read target met as proof that every tag is meaningful. The result only confirms the keys and values tested in the current run. For cost allocation, incident response, or compliance reporting, sample a few passing rows and confirm that Owner, Environment, CostCenter, and any data classification values match real team records.

Worked Examples:

Shared production scope below target

A six-resource inventory uses the required tags Owner, Environment=prod|stage|dev, CostCenter, and DataClass=public|internal|confidential with a 95 percent target. Four resources have all four tags with valid values, one resource is missing CostCenter, and one has DataClass=restricted. Resource coverage becomes 66.7%, Tag debt becomes 2 slot(s), and Largest gap points to one of the affected required tags. The right follow-up is to fix the missing cost center and decide whether restricted belongs in the approved data-class vocabulary.

Casing cleanup before policy evidence

An Azure virtual machine row has environment=prod while the required key is Environment. With Strict tag keys, the ledger reports Missing Environment. With Case-insensitive tag keys, the row can count as covered if the value is valid. That difference is a cleanup clue: the resource probably has the intended metadata, but the tag key spelling is not yet policy-ready.

Technical child resources excluded

A storage export includes directly taggable buckets and generated snapshot-copy rows that cannot carry the same metadata. Adding snapshot-copy to Ignored resource types removes those rows from Checked resources and adds an Ignored resources evidence row in Coverage Snapshot. That is defensible only when the ignored type is genuinely outside the tagging policy; otherwise the higher percentage is misleading.

Parser warning from a weak export

A pasted CSV includes a header with resource_id,type,provider,region but no tags or labels column. The snapshot can still show resource rows, but Parser warnings says the export did not include a tag column and every resource may look untagged. Fix the export before using Tag Remediation Queue, because the gap list is based on missing evidence rather than confirmed missing tags.

FAQ:

What tag formats can I paste?

The inventory can include a tag or labels column with key/value pairs separated by semicolons or pipes, such as Owner=payments;Environment=prod. A small JSON object in the tag column is also parsed.

Why does a resource show an invalid value instead of a missing tag?

The required key was found, but the value failed the current rule. That can happen when Require non-empty values finds a blank value or when an allowed-value list rejects the value.

Should I use strict or case-insensitive key matching?

Use Strict tag keys for policy evidence and Case-insensitive tag keys for discovery. A big difference between the two results usually means tag key casing needs cleanup.

Why did the result say no resources were available?

The inventory was empty after parsing, or every parsed row matched Ignored resource types. Remove the exclusion, add resource rows, or fix the CSV shape before using the coverage percentage.

Are pasted inventories sent to a backend for analysis?

No. Pasted text and selected files are read and analyzed in the browser, with a 1 MiB file limit for selected files. Treat copied CSV, DOCX, image, and JSON exports as sensitive operational evidence.

Glossary:

Cloud scope
The account, subscription, project, resource group, or export slice being audited.
Required tag
A tag key that must pass the current key and value rules for every checked resource.
Allowed values
The approved vocabulary for a required tag, written as a pipe-separated list after the key.
Tag debt
The total number of missing required keys plus invalid or blank values found in the audit.
Resource coverage
The percentage of checked resources where every required tag passes.
Remediation queue
The required-tag cleanup list sorted by priority and affected resources.

References: