Skip to content

Quickstart: a self-refreshing dashboard

Connect a warehouse, publish a dashboard against it, arm a schedule, and watch a real run land in the history.

This walkthrough ends somewhere specific: a run appearing in your dashboard's refresh history that nobody triggered. That is the product working. Everything before it is setup.

Before you start: the first quickstart done, a paid plan, and credentials for a warehouse you can read.

What you need from your warehouse

You will type these into the Dashies web app, not into your AI tool. Credentials never pass through the AI or the publish service.

Give Dashies a read-only login. It only ever runs SELECT, and a read-only role means a mistake in a query cannot become a mistake in your warehouse. On SQL Server a read-only login is required rather than merely advisable.

  1. Connect the warehouse.

    In the Dashies web app, open Data sources and add a connection for your engine: PostgreSQL, BigQuery, Snowflake, Redshift, Databricks, or SQL Server. The form asks for the connection details and for which tables, schemas, or datasets Dashies may read. Only what you allowlist there is readable.

    Test the connection before leaving the page. A connection has to be active before anything can be authored against it.

    If you are building for a team, create the connection from inside that workspace. A connection belongs permanently to the space it was created in, and a personal connection cannot back a workspace dashboard. See Connections and scope before you pick.

  2. Ask your AI for the dashboard.

    Name the connection and the numbers. For example:

    Build me a Dashies dashboard from my Snowflake connection showing revenue and order count by month and by plan for the last 12 months. Refresh daily.

    Your AI reads the schema, designs the grain, writes one SELECT per dataset, validates it against the connection, dry-runs the whole spec, and publishes.

  3. Read the publish report.

    Four things in it are worth your attention, and three of them are easy to skip past:

    In the reportWhat it is telling you
    Dashboard URLwhere the dashboard lives
    Datasetsthe mode each dataset resolved to, and why
    warningsnon-blocking advisories; read them, they are usually right
    obligationsa cross-check the server cannot do for you

    An obligation appears when a dataset reads more than one row source: a join, a CTE, a comma join, or a derived table. It is not a finding and not an error. It is the server saying that no static check can tell whether that join duplicated rows, so you have to. Do the check in step 5.

  4. Arm the schedule.

    If you asked for a cadence in step 2, it is already set. To change it, open Schedules in the web app and pick a cadence and a time in your own timezone.

    The cadence is a coarse choice (manual, hourly, daily, weekly, monthly) plus an optional interval and anchor: "every 6 hours", or "daily at 09:00 America/New_York". Schedules covers the combinations that are allowed and the ones that are refused.

  5. Cross-check one number before you share the link.

    Take one additive measure, sum it across the whole dashboard, and compare against a direct aggregate over the base table run in your own SQL client:

    select sum(amount) as revenue
from orders
where ordered_at >= current_date - interval '12 months'

    If the dashboard total is larger, a join has fanned out and every figure on the page is inflated by the same mechanism. Measure correctness is the page that explains why this check has no substitute.

Check it worked

The dashboard being live is not the thing to check. A run landing that you did not ask for is the thing to check.

  1. Open Schedules in the web app. Your dashboard should be listed with its cadence and a Next refresh time. If the cadence reads "On demand", the schedule was never armed and no run will ever happen.

  2. Wait for the next slot, then open the History tab. A new row should appear with a status, a row count, and a duration. That row is the proof: nothing you did caused it.

    A run can legitimately be a little late. Dashies schedules to the minute you pick and starts the run within about half an hour of it, so a dashboard ten minutes past its nominal time is healthy rather than broken.

  3. Expect "No change" sometimes. A successful run whose numbers came back byte-identical is marked as no change. That is a healthy state and it is labelled precisely so you can tell it apart from a stall.

  4. Do not check the dashboard's "Edited" timestamp. A refresh deliberately does not move it. Edited and Refreshed are two different clocks: Edited means the last time a person changed the dashboard, Refreshed lives on the Schedules page. A dashboard refreshing perfectly can show an "Edited" date from weeks ago.

If no run appears at all

Check the cadence first, then the plan. A schedule armed while paid keeps its cadence after a plan lapses, and each due run is then recorded as a skip rather than a failure, so nothing looks broken and nothing updates. On a workspace warehouse dashboard the plan that is checked is the plan of whoever created the data source, which is why a whole team's dashboards can stop at once. See Plans and what is gated.

Next

You now have the full loop. The pages that will save you the most time from here:

Last updated 2026-08-04