Grammar
In plain English: a query is one or morefield:value clauses joined by AND / OR, optionally prefixed with NOT. Field names can be dotted (system.crowdstrike.deployed). Values are typed — strings, booleans, enums, or relative dates like now-7d.
Concrete examples:
os:Windows— one clauseos:Windows AND tags:End-User— two clauses joined byANDtags:End-User AND NOT system.crowdstrike.deployed:true— three-clause query with negationlastOnline:now-7d— relative time (devices seen in the last 7 days)
Queryis oneClause, followed by zero or moreConnector + ClausepairsClauseis eitherfield:valueorNOTfollowed by another clauseConnectoris the literal wordANDorORFieldis a dotted identifier path (hostName,system.crowdstrike.deployed)Valueis one of the supported typesDurationisnow-followed by a number and a unit suffix (h,d,w,y)
Operators
There is no
=, <, >, <=, >=, contains, starts with, ends with, IN, or is empty operator. The grammar is intentionally minimal — composition is via AND / OR / NOT.
Value types
Confirmed top-level fields
These are the device fields surfaced by the search bar’s autocomplete on/devices. Field names, types, and descriptions are taken verbatim from the in-product hints.
Identity & basics
Time fields
User association
Location
Metadata (hardware, identifiers)
Allmetadata.* fields are strings:
Tags
Tag values are whatever you’ve defined in Settings → Tags. For example:
End-User, EMEA, NA, APAC, Mac, BYOD, Server, VM, Stock.
Nested collections
These accept dot-notation drill-down or specialised query forms:Vitals (system.* prefix)
Each connected integration is exposed as a prefix with four boolean sub-fields:
Your tenant’s set depends on which integrations are connected.
Device-type values
metadata.device_type is an enum, but values are tenant-defined rather than universal. For example:
EndUserEndUser - EOLEndUser - LegacyMacs - OS XWindows ServerLinuxUnmanaged (BYOD) - Default Naming ConventionUnmanaged - Review (potential corportate)
metadata.device_type: and look at suggestions) to see your tenant’s values.
Time values
The autocomplete after: on a time field offers:
How time matching is interpreted by the system (within range vs exact) is not exposed in autocomplete. Test with known data before relying on it in saved views.
Verified test results
Example queries (with theActive filter applied). Counts are illustrative and will vary by tenant:
Worked examples
- Coverage gap
- Broken agent
- Drift
- Excluded from baseline
Saved views
Build a query → click the floppy icon in the footer → name → choose visibility (Private / Team / Everyone). Saved views appear in the Default View ▾ dropdown top-right and are the basis for Scheduled Reports.What’s not in the grammar
Tested against autocomplete and Enter-submit. The following patterns either silently don’t filter or aren’t suggested:- Comparison operators
<,>,<=,>= contains,starts with,ends withIN (...)/NOT INis empty/is not empty
AND/OR/NOT over field:value, use the API.
See also
Query Language tutorial
Introductory walkthrough
Devices
Where you’ll write most queries
Tags & Logic Engine
Same syntax drives tag rules