Log every Bitbucket pipeline run to a Google Sheet

Every time a Bitbucket pipeline finishes, we append one row to a Google Sheets deploy log with the details your audit team needs.

Deterministic Code
BitbucketGoogle SheetsEngineeringOperationsData Sync
PromptCreate

Every time a Bitbucket pipeline finishes running (success, failed, or stopped), append one row to a Google Sheets deploy log. The goal is an audit-friendly, append-only ledger of every CI/CD run so we have a trustworthy record for later analysis or SOC 2 review, without paying for a separate analytics tool.

Trigger: a Bitbucket webhook subscribed to the pipeline completion event for the workspace. Bitbucket emits an event on every finished pipeline regardless of outcome, and the payload already contains everything we need, so no follow-up Bitbucket call is required in the happy path.

Step 1. Parse the webhook payload. Pull out: the repository full name (workspace/repo_slug), the target ref (branch, tag, or commit hash), the commit SHA, the commit author (display name or username), the trigger reason (push, manual, schedule, pull request, and so on), the pipeline state and result (SUCCESSFUL, FAILED, STOPPED, ERROR), the pipeline build number and UUID, and the created_on and completed_on timestamps.

Step 2. Check the repository full name against an allow-list configured on the workflow. If the repo is not on the list, stop cleanly without writing anything. The allow-list is a plain array of repository full names (for example, acme-co/frontend, acme-co/backend).

Step 3. Compute the duration in seconds from created_on and completed_on. If either timestamp is missing (rare), leave the duration cell blank rather than guessing or defaulting to zero.

Step 4. Build the pipeline URL as https://bitbucket.org/{workspace}/{repo_slug}/pipelines/results/{buildNumber} using the workspace, repo slug, and build number from the payload.

Step 5. Append a single row to the configured Google Sheet using the Google Sheets Append Values operation with valueInputOption=USER_ENTERED so the timestamp and URL render naturally. The columns, in order, are: timestamp (ISO 8601 UTC of completion), repository full name, branch (or tag/commit ref), commit SHA, commit author, trigger reason, pipeline status, duration in seconds, and the pipeline URL.

Append-only invariant: the workflow must never update or delete existing rows, even to fix a duplicate. If the same webhook fires twice, allow the second row to land as-is. The whole point of this ledger is that historical rows are immutable, so audit consumers can trust it.

Configuration knobs to expose to the user: the Google spreadsheet ID and tab name (default Sheet1), the allow-list of repository full names, and an optional column-mapping override for teams whose sheet already has more columns than the default nine.

Failure behavior: if the Google Sheets append is rate-limited or transiently fails, retry with exponential backoff. If it still fails after retries, log the dropped event with enough detail to reconstruct it manually, but do not attempt any compensating writes. If the Bitbucket webhook payload is malformed, log and drop without writing to the sheet.

This is a deterministic step-by-step workflow with no reasoning required, which is why it is a code workflow rather than an agent.

Additional information

What does this prompt do?
  • Watches your Bitbucket workspace for finished pipeline runs, whether they succeeded, failed, or were stopped.
  • Appends one row to your Google Sheet with the timestamp, repository, branch, commit, author, trigger reason, status, duration in seconds, and a link back to the pipeline run.
  • Runs in append-only mode: never updates or deletes rows, so the ledger stays trustworthy for later analysis or SOC 2 review.
  • Only logs the repositories you name in an allow-list, so noisy or unrelated repos stay out of your log.
What do I need to use this?
  • A Bitbucket workspace where you can add a pipeline webhook
  • A Google account with edit access to the sheet you want to log into
  • A Google Sheet with a header row already in place for your deploy log
  • The list of repositories you want logged (your allow-list)
How can I customize it?
  • Edit the allow-list to change which repositories get logged
  • Add, remove, or reorder columns to match how your team wants to slice the data
  • Point the workflow at a different sheet or tab for production versus staging pipelines

Frequently asked questions

Does this log successful runs too, or only failures?
Every finished pipeline is logged, including successful, failed, and stopped runs, so you have a complete history and not just the bad ones.
Can I limit the log to certain repositories?
Yes. You give the workflow an allow-list of repository names, and pipelines from any repo outside that list are ignored.
Will this ever change or delete rows in my sheet?
No. The workflow only appends new rows. Existing rows are never edited or removed, which is what makes the log usable as an audit trail.
Do I need a paid Bitbucket plan for this?
No. Pipeline webhooks are available on any Bitbucket Cloud plan that includes Pipelines, including the free tier.
Will this slow down my builds?
No. Logging happens after each pipeline finishes and does not touch the build itself, so build times are unaffected.

Give your CI/CD an audit-ready paper trail.

Every deploy, every rollback, and every stopped run captured in one Google Sheet your auditors will actually trust.