Skip to content

GitHub Monitoring Workflow

Proposed owner: Funnel Agent (or dedicated cron-only job)

What It Does

Sam monitors 4 FuturHealth GitHub repositories for new commits. The intent is to correlate code changes with conversion rate changes — if a funnel deploy happened right before CVR dropped, Sam should catch it.

Repositories Monitored

RepoWhy It Matters
funnelMain funnel app — quiz logic, routing, UX
funnel-cmsSanity CMS schema (updated daily, high commit frequency)
landing-pagesLanding page code (A/B test deploys here)
checkoutCheckout system (payment flow changes affect CVR)

FuturHealth org: 74 private repos total. These 4 are the highest-impact for conversion.

Auth: Authorization: Bearer $GITHUB_PAT_TAGIATELLE (broadest access token)

How It Works

Shell script: scripts/github-funnel-monitor.sh

For each repo:

  1. GET https://api.github.com/repos/FuturHealth/{repo}/commits?per_page=5
  2. Compare latest SHA to state stored in memory/github-watch-state.json
  3. If new commits: update state file, append to memory/funnel-changes.md with details
  4. If significant CVR correlation: DM John on Slack

State file: memory/github-watch-state.json

Current Status: Broken

The cron job handling this is timing out:

json
{
  "lastRunStatus": "error",
  "lastError": "cron: job execution timed out",
  "lastDurationMs": 90008,
  "consecutiveErrors": 1
}

The job has a 90-second timeout. It's consistently hitting exactly 90,008ms — the timeout is being reached, not slightly exceeded. This suggests:

  • GitHub API latency under network conditions on the Ubuntu server
  • The job is doing too much in one turn (4 API calls + file reads + writes + potential Slack DM)
  • 90 seconds may not be enough for all 4 repos in sequence

The Over-Monitoring Problem

GitHub is being monitored by two systems simultaneously:

SystemFrequencyWhat Happens
Cron jobEvery 30 minutesIsolated session, times out
Heartbeat3×/day (at 10am, 2pm, 6pm PT)Main session, silently logs

John's feedback: Sam was reporting commit changes every 30 minutes to Slack. John asked to stop this at least 5 times. HEARTBEAT.md was updated with:

## ⛔ STOP — READ BEFORE DOING ANYTHING ⛔
- DO NOT check GitHub
- DO NOT post to sam-chat
- John has asked FIVE TIMES to stop reporting commits every 30 min. RESPECT THIS.

Despite the HEARTBEAT.md update, the cron job continues running and timing out.

Alert Logic

When to alert John:

  • Only if a code change correlates with a >5% conversion rate shift
  • Log everything silently to memory/funnel-changes.md

In practice: The cron job is supposed to alert via Slack DM to John, but it times out before completing.

funnel-changes.md

The commit log file is maintained at workspace/memory/funnel-changes.md. This file is:

  • Updated when new commits are detected
  • Used as context for correlating CVR changes with deploys
  • Read during heartbeat check windows

Why This Belongs in the Funnel Agent

Problem with current setup:

  • GitHub monitoring is intimately related to funnel CVR — it's about watching for funnel code changes
  • Having it as a standalone cron job separate from the funnel monitoring heartbeat creates duplication
  • The cron job doesn't have the PostHog context needed to do correlation

Dedicated Funnel Agent approach:

  • GitHub check and PostHog CVR check happen in the same agent turn
  • Correlation is immediate: "Commit at 2pm, CVR dropped 8% by 6pm — likely related"
  • No separate cron job needed — folded into the 3×/day funnel check window
  • Lighter context: the funnel agent doesn't carry creative or Braze history

Immediate fix regardless:

  • Disable the current cron job (it's broken and conflicting with heartbeat)
  • Rely solely on the heartbeat's GitHub check at 3×/day windows
  • This is John's preference anyway

See also: Automation & Cron | Funnel Monitoring | Known Issues

FuturHealth Internal — Confidential