Skip to content

feat(web-analytics): staleness-first warm order + per-team progress log #33743

feat(web-analytics): staleness-first warm order + per-team progress log

feat(web-analytics): staleness-first warm order + per-team progress log #33743

name: Monitor GitHub Rate Limit
# Polls /rate_limit and emits one PostHog event per resource, so the per-repo
# GITHUB_TOKEN bucket is observable as a time series — that bucket is the slice
# of GitHub API usage that the org-level API Insights dashboard does not cover.
#
# Trigger strategy: ride real PR/master events for density (synchronize fires
# on every PR push and is the dominant signal source on this repo), with a
# 30-minute schedule as a quiet-time floor. A delayed scheduled tick is fine
# here — events fill the gap.
#
# Alerting belongs downstream in PostHog (windowed thresholds, attribution by
# repo) — not in the workflow itself. Keep this file focused on emission.
#
# A burn-rate alert is wired up downstream in PostHog (DevEx project, id 347861) —
# these are live PostHog resources, not config in this repo:
# - Insight "GitHub core rate-limit — early-window peak utilization" (short id
# iGGXQ1mF): per hour, the peak `core` utilization among samples with >30 min
# left in the reset window (reset_in_seconds > 1800), which filters out the
# harmless pre-reset sawtooth peak.
# - A PostHog alert on that insight fires when it exceeds 0.8 (80%) — i.e. the
# bucket is burning early, not just spiking right before its hourly reset.
# - A Slack destination relays the firing alert to #alerts-devex (and email).
# To change the threshold/window, edit the insight + alert in PostHog, not here.
on:
pull_request:
types: [opened, synchronize]
push:
branches: [master]
schedule:
- cron: '*/30 * * * *'
workflow_dispatch:
permissions:
contents: read
jobs:
poll:
runs-on: ubuntu-latest
timeout-minutes: 3
# Forks don't get secret access on pull_request, so the capture would
# no-op anyway — skip the run entirely to avoid noise.
if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository
steps:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
sparse-checkout: |
.github/scripts/monitor-github-rate-limit.js
sparse-checkout-cone-mode: false
- name: Poll GITHUB_TOKEN bucket and emit to PostHog
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
env:
POSTHOG_DEVEX_PROJECT_API_TOKEN: ${{ secrets.POSTHOG_DEVEX_PROJECT_API_TOKEN }}
with:
script: |
const script = require('./.github/scripts/monitor-github-rate-limit.js')
await script({ github, context, core }, { source: 'github_token' })
# The setup-action offload bucket (posthog-devex-general) is a
# separate 15k installation bucket from GITHUB_TOKEN. Mint its token
# and poll /rate_limit through it so its core budget is observable as
# its own series. /rate_limit reads don't consume the budget they
# report, so this doesn't distort the measurement. No-ops until the
# org secret exists (continue-on-error mint + empty-token guard).
- name: Mint posthog-devex-general token
id: devex-token
continue-on-error: true
uses: actions/create-github-app-token@1b10c78c7865c340bc4f6099eb2f838309f1e8c3 # v3.1.1
with:
client-id: ${{ secrets.GH_APP_POSTHOG_DEVEX_GENERAL_APP_ID }}
private-key: ${{ secrets.GH_APP_POSTHOG_DEVEX_GENERAL_PRIVATE_KEY }}
- name: Poll posthog-devex-general bucket and emit to PostHog
if: steps.devex-token.outputs.token != ''
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
env:
POSTHOG_DEVEX_PROJECT_API_TOKEN: ${{ secrets.POSTHOG_DEVEX_PROJECT_API_TOKEN }}
with:
github-token: ${{ steps.devex-token.outputs.token }}
script: |
const script = require('./.github/scripts/monitor-github-rate-limit.js')
await script({ github, context, core }, { source: 'posthog-devex-general' })