Polymarket Data in Grafana

• Load books/prices/metrics into DuckDB, Postgres, or ClickHouse first; Grafana queries the store, not the REST endpoint directly.
• A duckdb datasource or postgres connection with the (market, ts) schema fits Grafana's time-series model exactly.
• Variable pickers: a Grafana variable fed by SELECT DISTINCT market FROM books makes one dashboard cover all markets.
• Alerts: thresholds on spread or one-sided flags trigger Slack/PagerDuty from the same panels.

• Mid-over-time with bid/ask as steps — read the spread as the gap between two lines.
• Depth bars: top-of-book bid vs ask per interval (SELECT time_bucket + avg(bid_depth), avg(ask_depth)).
• Settlement panels: one-sided fraction per market over the final hour, so resolve-behavior is visible at a glance.
• Volume: cumulative traded volume as a step-line with the same timestamp axis.

Panel thresholds: Grafana auto-reduces to its own cadence, so minute-bucketed queries display cleanly even over 250ms data.

Downsample at query time (time_bucket) rather than sinking 250ms rows to a panel; keep raw rows in storage.

Books, prices, and metrics come back over the same endpoints at the same 250ms resolution, so a dashboard needs one schema, not three.

Point Grafana at the DuckDB or Postgres store, define a $(market) variable from SELECT DISTINCT, and build two panels: mid-with-bid/ask steps, and depth bars per interval.

Alerts live on the same panels: threshold a spread metric and page via Slack when a crossed frame appears — the pattern that flags final-minute behavior on live markets.

Every Grafana number traces to a frame column; if a panel total disagrees with the CSV export for the same window, the bucket boundary differs — fix the query, not the export.

Alerts fire on stored data, not on live API state, so Grafana keeps working across a PRD outage.

Grafana is the ops surface: panels over a stored copy, alerts on conditions that matter, and a read path that never competes with the live pull — dashboards survive source outages because the store is the source of truth.

The honesty worth keeping is bucketing: Grafana downsamples to its render cadence, so minute bars from 250ms frames display cleanly; raw frames stay in tables for point-in-time work.

The one-sided settlement panel over final-hour frames is the operator's early-warning for how a market is resolving, built from the same flags the CSV carries.

First dashboard: one market, two panels (mid steps, top-of-book depth bars), driven by a market variable from the store. If the mid panel tracks the site within a tick over a five-minute window, the wiring is proven.

Then wire one alert: spread above a fixed threshold posts to Slack once (not once per frame) — alert deduplication on timestamp series is an operator skill you want checked before it matters.

Grafana converts the archive into a picture people can act on: mid steps, top-of-book depth, and settlement flags over the final hour, all reading from your own store so panels survive source outages.

The operator habit that pays is deduplicated alerts — spread thresholds and crossed-frame flags that post once, not once per frame — because alert fatigue is what silently kills monitoring in a year.

Keep Grafana on the store and the store fed by the pull; the dashboard then answers two questions live: what is trading now, and which market is behaving like it is about to settle.

• API data guide
• Data download
• Order book data
• MCP server