Appearance
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
| Repo | Why It Matters |
|---|---|
funnel | Main funnel app — quiz logic, routing, UX |
funnel-cms | Sanity CMS schema (updated daily, high commit frequency) |
landing-pages | Landing page code (A/B test deploys here) |
checkout | Checkout 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:
GET https://api.github.com/repos/FuturHealth/{repo}/commits?per_page=5- Compare latest SHA to state stored in
memory/github-watch-state.json - If new commits: update state file, append to
memory/funnel-changes.mdwith details - 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:
| System | Frequency | What Happens |
|---|---|---|
| Cron job | Every 30 minutes | Isolated session, times out |
| Heartbeat | 3×/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