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, or csv.
  • --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 query with kl history and kl diff.