kl query
kl query is the inspection command for KiloLock’s queryable state model.
It supports two modes:
- read-only SQL against the KiloLock database
- backend-native resource and history lookups
When to use it
Use kl query when you want:
- inventory by type
- resource-level investigation
- blast-radius style exploration
- quick state/resource history lookups without hand-written SQL
Core forms
SQL query
kl query "SELECT name FROM states ORDER BY name"
Query from a file
kl query -f docs/queries/inventory_by_type.sql --format table
Resource lookup
kl query resource big-state --address time_sleep.slow_a
Resource history lookup
kl query history big-state --address time_sleep.slow_a
Important flags
-f: read SQL from a file, or-for stdin.--format:table,json, orcsv.--state-url: select a state directly instead of relying on backend discovery.--timeout: bound SQL execution time.--token: use bearer auth for cloud/admin API access.
Meaningful examples
Count resources by type
kl query "SELECT type, COUNT(*) FROM resources GROUP BY type ORDER BY 2 DESC"
This is the fastest “what is actually in this state?” question.
Feed a checked-in SQL query
kl query -f docs/queries/blast_radius.sql --format json
Useful for repeatable investigation and for sharing a query with teammates.
Investigate one resource
kl query resource big-state --address time_sleep.slow_a
Use this when a single address is suspicious and you want current data without scanning a whole table.
Review one resource’s history
kl query history big-state --address time_sleep.slow_a
This is the natural follow-up after a weird apply, manual repair, or rollback.
Notes
- SQL mode is read-only by design.
- For long-lived reusable queries, prefer the checked-in files in docs/queries.
- For operational investigation, pair
kl querywithkl historyandkl diff.