Monday to BigQuery: How to Move Your Data

Moving Monday into BigQuery turns work tracking into something you can analyse across teams and quarters. Monday shows you a board. It does not tell you how long items sit in a status across the whole company, or whether a process change helped, and those questions need history and joins.

This guide covers the managed path with Airbyte. Two things about this connector are unusual and worth knowing before you build: incremental sync works through the activity log rather than a timestamp cursor, and the actual content of your boards arrives as generically typed nested values rather than as columns.

Monday to BigQuery at a glance:

Why move data from Monday to BigQuery?

Two situations account for most of these pipelines.

The first is analysis across boards. Monday is organised around individual boards owned by individual teams, and questions about the whole organisation, how much work is in flight, where it stalls, how that has changed, cut across all of them. A warehouse is where that view exists.

The second is joining work to outcomes: delivery items against revenue, support requests against churn, project effort against cost. Monday holds one side and your other systems hold the rest. If you only need a board's own dashboard, Monday already does that.

What do you need before you start?

One of these is a fact about your Monday plan rather than a setting, and it decides your schedule:

A personal API token or an OAuth application. The token is generated from your profile picture menu under Developers, and an OAuth application is created under My Apps. The connector requests read scopes covering boards, workspaces, users, account, updates, assets, tags and teams. The Monday source documentation lists them.

A service account to own the token. A personal API token belongs to a user and inherits their visibility, so a token created against an individual sees the boards they can see and stops working when they leave. That is a data completeness question as much as an operational one.

Your plan's activity log retention period. This is the number that sets your sync frequency, for the reason in the next section. It varies by Monday plan and is worth looking up rather than guessing.

A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match whatever you intend to join against, since it cannot be changed after creation.

Rate limits are unlikely to trouble you here. The connector should not run into Monday API limitations under normal usage, so your constraints are visibility and retention rather than throughput.

How do you build a Monday to BigQuery pipeline in Airbyte?

Step 1: Look up your activity log retention

Check what your Monday plan retains activity logs for, because that period is the outer bound on how long you can safely go between syncs. It is the single most useful thing to establish before configuring anything, and it is easy to look up and easy to never think about.

Step 2: Configure the Monday source

Click Sources in the left navigation, then New Source, and select Monday, following adding a source. Choose API token or OAuth as the authorisation method and supply the credentials. If you use a token, remember it carries one user's view of the account.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project, dataset and service account key. Batched standard inserts is the default and is ample, because work tracking data is small by warehouse standards even across a large account.

Step 4: Select activity logs alongside everything else

Click Connections, then New connection, and select streams with a sync mode each. Boards and items are the core, users and teams resolve the identifiers in them, and activity logs is not optional if you want incremental sync, because it is the mechanism rather than a nice extra.

Set the frequency against the retention figure from step 1 rather than against how fresh anyone would like the dashboard. Daily is comfortable on most plans and the point is to stay well inside the window rather than to be current.

Why does incremental sync depend on your plan?

Because the connector does not find changes by filtering on a modified timestamp. Incremental sync for the boards and items streams relies on the activity logs stream: board and item identifiers are extracted from activity log events and used to selectively sync only the records that changed.

That is a clever design and it inherits a limit from Monday. Activity logs are retained for a period that depends on your plan, so if the time between syncs exceeds that retention, the events describing what changed are gone and those changes are not captured. The records stay stale in BigQuery and nothing reports it.

So a paused connection is more expensive here than on a cursor-based source. With a timestamp cursor you resume and catch up; here the evidence of what changed has expired. Sync comfortably inside your retention window, alert on failures rather than letting a broken connection sit over a holiday, and run a periodic full refresh if you ever suspect a gap.

Where is the actual content of my boards?

Inside nested structures rather than in columns, which surprises people expecting a board to arrive as a table. The boards stream carries column definitions, appearing in your destination as nested data typically named boards.columns. The items stream carries the values, appearing as items.column_values.

Each column value carries an identifier, a text representation, a type and a value. So a board with status, owner and due date columns does not give you three columns, it gives you an array of three generically shaped entries per item. Some types add more: connect boards and dependency columns include an array of linked item identifiers.

The modelling job is therefore to pivot those values into real columns, joining the definitions from boards so each one has a meaningful name. Do it once per board shape in a BigQuery view and point analysts there. Left raw, this dataset is technically complete and practically unusable, which is the usual failure mode on work management sources.

Frequently asked questions

Why are some changes missing from my incremental sync?

The time between syncs probably exceeded your plan's activity log retention. Incremental sync identifies changed boards and items from activity log events, so once those expire the changes cannot be found.

Do I need the activity logs stream?

For incremental sync on boards and items, yes. It is the mechanism the connector uses to identify changed records rather than an optional extra.

Where are my board columns?

Column definitions come with the boards stream as nested data, and values come with the items stream as column values carrying an id, text, type and value. Pivot them into real columns in a view.

Why can I not see some boards?

A personal API token carries the visibility of the user who created it. Use an account with access to everything you need to replicate.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views pivoting column values into named columns, which is where this dataset becomes usable.

Get your Monday data into BigQuery

Look up your activity log retention first, because it bounds how long you can go between syncs and a gap there is silent. Use a service account for the token, always select the activity logs stream, alert on failures, and build the pivoting views before anyone opens the raw tables.

Airbyte's connector catalog includes 600+ pre-built connectors, so work tracking can sit beside delivery and revenue sources. For another work management source in the same position, see Jira to Databricks, and for a source whose upstream is similarly hand-maintained, Airtable to BigQuery.

Start syncing now →