Weekly Airbyte connection cost cleanup review in Slack

Every Monday at 9am, run a cost-hygiene review of every Airbyte connection in the workspace and post a single Slack message to the data team channel calling out the ones that could be paused, deleted, or investigated. The goal is to catch connections that are still enabled and burning Airbyte credits when nothing downstream actually uses the data anymore. This is not a status digest — a daily green/red readout already exists for that. This one recommends specific pruning actions.

Start by calling Airbyte's List Connections operation to get every connection across the accessible workspaces. For each connection, call List Jobs scoped to that connection to pull the last 30 days of sync activity. When a job's summary row count isn't already available in the list response, follow up with Get Job Details to read the rowsSynced metric. Paginate through results as needed.

Classify each connection into exactly one of four buckets based on that 30-day window:

• healthy — the connection is enabled, recent syncs are succeeding, and rows are being produced. No action needed, do not include it in the Slack message.

• idle — the connection is enabled and its recent syncs are technically succeeding, but it has synced 0 rows for 14 or more consecutive days. These are the classic credit-burners. Recommended action: pause or delete.

• failing — the connection has multiple consecutive failed jobs in the window (three or more in a row, or a clear pattern like repeated auth errors). Recommended action: investigate.

• already-disabled — the connection is already paused or inactive. Recommended action: consider deleting if it has been disabled for weeks and nobody has come asking.

Then compose one Slack message and post it with the Slack Bot Send a Message operation to the data team channel. Do not spam one message per connection — a single, scannable message. Skip the healthy ones entirely. For every connection that lands in idle, failing, or already-disabled, include one line with: the connection name, the suggested action, and a short reason. Match the phrasing style of these examples so the message reads like a real recommendation, not a data dump:

• "pause: 0 rows synced in 21 days, no downstream consumers"

• "investigate: 4 straight failures on auth"

• "delete: disabled since March, nobody has re-enabled it"

Prioritize the list — put the connections most worth paging someone on at the top (long-idle expensive-looking ones, then repeated failures, then long-disabled). If literally every connection is healthy this week, still post a short message saying so, so the team knows the review ran. Keep the tone useful and concise — this is a FinOps recommendation, not a status report.

Context worth baking in: Airbyte's own auto-disable only kicks in after 14 consecutive failures or 100 total failures, and it never fires on idle-but-succeeding connections that still cost credits every run. That gap is exactly what this workflow closes.