mcpField
C
checking-deploy-timing

checking-deploy-timing

github.com/posthogCloud & DevOps95160 installsUpdated today
Repository

About checking-deploy-timing

checking-deploy-timing helps PostHog team members verify when a change reached a particular environment or region. It uses hidden deploy annotations as the source of truth and checks commit ancestry to confirm that a deployment includes the target merge commit.

Key features

  1. 01Search deploy annotations
  2. 02Filter deployments by environment and region
  3. 03Compare deploy and merge timestamps
  4. 04Verify deployed commit ancestry
  5. 05Distinguish production from internal dev

Use cases

  1. 01Find when a PR reached prod-us
  2. 02Verify when a change shipped to prod-eu
  3. 03Separate deploy timing from metric changes
  4. 04Check whether a later deploy includes a target commit

MCP support

The skill uses PostHog's `posthog:annotations-list` tool to find deploy annotations; it also uses GitHub CLI to query pull requests and commit ancestry.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/posthog/ai-plugin --skill checking-deploy-timing

After installing, type/checking-deploy-timingin Claude Code to confirm it loaded.

Details

From the project README

Checking when something was deployed

PostHog's CI writes a deploy marker into the project as an annotation every time a commit ships to an environment. These annotations are hidden_in_user_interface: true, so they don't show in the UI and are easy to forget — but they are the source of truth for "when did this go out". Always check them when staff ask about deploy timing, rather than inferring from when a metric or event volume changed (that conflates a capture change with a query/code change).

The deploy annotations

List them with posthog:annotations-list using {"search": "deploy"}. Each deploy marker looks like:

  • content: Deployed PostHog/posthog@<sha> to <env> — env is prod-us, prod-eu, or dev
  • creation_type: GIT
  • scope: organization
  • hidden_in_user_interface: true
  • date_marker: the deploy time (UTC)

They're returned newest-first; paginate with offset if you need to go further back.

Workflow

  1. Find the change's merge commit. Identify the PR (e.g. gh search prs --repo PostHog/posthog --author <user> "<keywords>"), then gh pr view <n> --repo PostHog/posthog --json number,title,mergedAt,mergeCommit,state. Note the merge commit SHA and mergedAt.

  2. List the target environment's deploys around the merge, oldest-first. Match the region the user asked about (prod-us for "the US", prod-eu for "the EU"). The annotations come back newest-first, so don't just take the first ... to <env> match on page 1 — that's the most recent deploy. Paginate (with offset) until you reach markers around mergedAt, then consider that environment's deploys in chronological order, starting with the first whose date_marker is after mergedAt. Check them earliest-first in step 3.

  3. Confirm the deployed commit actually contains the merge commit. A later date_marker is necessary but not sufficient — a deploy can fire just after the merge yet build a slightly older commit. Verify ancestry:

    gh api repos/PostHog/posthog/compare/<merge_sha>...<deployed_sha> --jq '{status,ahead_by,behind_by}'

    behind_by: 0 with status ahead or identical means the deployed commit includes the merge — that's your answer. If behind_by > 0, this deploy predates the change; move to the next newer deploy of that environment (the next one chronologically) and re-check. The first deploy that passes is the one that shipped the change.

  4. Report the deploy time (and PR/commit) for the region asked about. Mention other regions if relevant — prod-us and prod-eu usually deploy minutes apart but not simultaneously.

Notes

  • "Live in the US" = prod-us; "the EU" = prod-eu. dev is the internal staging environment, not customer-facing.
  • For a query-runner / read-path change, the new behaviour applies retroactively to all data once deployed — so you can't time it from event volume, only from the deploy annotation. For a capture change, event volume for the new property is a secondary cross-check, but the annotation is still the authoritative deploy time.

Comments

Markdown supported