Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →supabase/clickhouse-logs-queries
Write, review, and migrate Supabase logs queries against the ClickHouse-backed `logs` table (the `logs.all.otel` analytics endpoint). Use this whenever a task involves Logs Explorer SQL, the `log_attributes` map, querying a log `source` (edge_logs, postgres_logs, auth_logs, etc.), translating an old BigQuery `cross join unnest(metadata)` logs query to ClickHouse, or wiring analytics log SQL in `apps/studio/data/logs` and `apps/studio/components/interfaces/Settings/Logs`. Reach for it even when t
Passed 22 of 22 test cases with the skill, and 9 of 22 without it.
and 14 more in the full report
13 fixed9 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
Translate this legacy BigQuery query to Supabase Logs Explorer ClickHouse SQL: SELECT timestamp, m.request.method FROM `project.supabase_logs.edge_logs` CROSS JOIN UNNEST(metadata) AS m WHERE m.request.method = 'POST' LIMIT 50
| Checked | Without skill | With skill |
|---|---|---|
| Replaces UNNEST with direct bracket lookup log_attributes['request.method'] | Missed | Passed |
| Queries from logs with source = 'edge_logs' | Missed | Passed |
The instructions your model reads when the skill loads.
Supabase logs live in a single ClickHouse logs table, served by the
logs.all.otel analytics endpoint. Every log line from every part of the stack
is one row in this table, tagged by a source column. This replaces the older
BigQuery model, where each service had its own table and fields were reached
through cross join unnest(metadata).
Two kinds of work use this skill, and they share the same SQL model:
If you are converting an existing BigQuery logs query, read references/bigquery-migration.md for the full translation table.
Each row has a small set of real columns. Everything specific to a service lives
in log_attributes.
| Column | Type | Notes |
|---|---|---|
id | String | Unique log identifier. |
timestamp | DateTime64 (UTC) | When the log was produced. Order/compare it directly. |
event_message | String | The raw log line. |
severity_text | String | Log level, when the source sets one. |
source | String | The service the log came from. Always filter on this. |
log_attributes | Map(String, String) | Structured per-source fields, keyed by a dotted path. |
timestamp is formatted like 2026-06-22T09:34:06.215000 (ISO 8601, microsecond
precision, no trailing Z). In the Logs Explorer the selected time range is
applied for you, so you rarely need to write a timestamp filter by hand.
A minimal, well-formed query. Lead with a comment naming the query, filter by
source, and always limit:
test cases passed, vs 9 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.