Getting started
- Install the CLI
- Set up an API Client in SYNQ by clicking
Add client
with the following scopes
Edit SQL Tests
Edit Automatic Monitors
Edit Custom Monitors
- Run
synq-monitors
using the credentials from above
Defining monitors in code
Create a YAML file where you’ll be managing the monitor setup, for example,synq_monitors.yml
. You can split your configuration up into multiple files and use namespaces to manage individual domains or data products independently.
Using NamespacesMonitors in one namespace are isolated from those in another, which helps you:
- Avoid conflicts when multiple teams manage monitors in parallel.
- Keep different pipelines or environments separate (e.g., dbt models in CI vs. external tables in prod).
- Apply ownership, defaults, and alerts consistently within a group.
namespace
at the top of your YAML file, or override it inside individual monitor definitions when needed.Configuring a monitor
You can define all custom monitor types as code (freshness
, volume
, custom_numeric
, and field_stats
). Read more about each monitor type.
Obtaining IDs from the SYNQ UI
When configuring a monitor,monitored_id
is the full table, as represented by SYNQ. You can locate this ID by navigating to a table in the SYNQ UI (using the catalog or search functionality) and copying the ID from the URL.
In the example below, bq-synq-demo::nyc_taxi::financial_statement
will be the ID.

Understanding the configurable parameters
You can see all the configurable parameters in the Available YAML Fields in the readme. For more examples of configuring individual monitors, see our Examples repo.Verifying monitors in the SYNQ UI
If you navigate to theSettings
menu for a monitor, you can verify that it’s created by code by seeing the Monitor was created via API and can't be managed in APP
label.
