Track GitHub Activity Alongside Business Metrics

Does Shipping Faster Mean Growing Faster?

Every engineering team believes that shipping more features drives growth. But does it? The answer is buried in the gap between your GitHub activity and your business metrics. Commits, PRs, and releases happen in GitHub. Revenue, signups, and churn happen in Stripe and your analytics tool. Nobody looks at both together.

Overlaying shipping velocity with business outcomes answers questions that engineering and product teams argue about constantly:

• Does shipping more features actually increase revenue?
• Do bug fix releases reduce churn?
• Is there a lag between shipping and business impact?
• Are we shipping the right things, or just shipping fast?

What to Track From GitHub

Commit Frequency

Weekly commit count is a rough proxy for engineering output. It's noisy (not all commits are equal), but over time, trends in commit frequency correlate with shipping velocity.

Pull Requests Merged

More meaningful than raw commits. PRs merged per week represents completed units of work that made it through review. This is a better signal for "how much did we actually ship?"

Releases / Deployments

The most direct measure of what reaches users. Track your release count or deployment frequency. This is what customers actually experience.

Issues Closed

Tracks bug fixes and feature completion. Overlay with churn rate to see if fixing bugs actually reduces customer loss.

Setting Up the GitHub Connection

Via API

GitHub's REST API provides access to commits, PRs, releases, and issues. In TotalKPI:

1. Create an API data source
2. Set the endpoint to the GitHub API for your repo (e.g., https://api.github.com/repos/owner/repo/commits)
3. Add your GitHub personal access token in the Authorization header
4. Use array mode to fetch multiple data points: $array:path:valueKey:dateKey
5. Set polling to daily

For commit count, you can use the stats/commit_activity endpoint which returns weekly commit counts - perfect for time-series tracking.

Via Webhook

Use GitHub webhooks to push events to TotalKPI in real-time:

1. Create an inbound API key in TotalKPI
2. Add the webhook URL to your GitHub repo settings
3. Select events: push, pull_request, release
4. Map the incoming payload to a data source in TotalKPI

This gives you real-time data points every time a PR is merged or a release is published.

Via n8n or Zapier

If you prefer, use n8n or Zapier's GitHub integrations to aggregate and push data on a schedule. This lets you transform the data (e.g., count PRs merged this week) before sending it to TotalKPI.

Overlays That Matter

PRs Merged vs MRR

The big question: does shipping correlate with revenue? Overlay weekly PRs merged with Stripe MRR growth. A strong positive correlation with a 2-4 week lag means your engineering work is driving business results. A weak correlation might mean you're shipping features that don't move the needle.

Release Frequency vs New Signups

Track how often you release and overlay with new user signups. Product-led growth depends on continuous improvement. If release frequency correlates with signups, your product improvements are attracting new users. If not, your growth might be driven by marketing rather than product.

Bug Fix Releases vs Churn Rate

This is a powerful one. Track releases tagged as bug fixes or patches and overlay with your monthly churn rate. If bug fix releases correlate with reduced churn (with a short lag), you have clear evidence that engineering investment in stability directly impacts retention.

Issues Closed vs Customer Satisfaction

If you track NPS, CSAT, or support ticket volume, overlay these with GitHub issues closed per week. This connects engineering work directly to customer experience metrics.

Reading the Results

Strong Correlation (>0.5) With Lag

Your engineering output drives business results, but it takes time for users to experience and respond to changes. Use the lag duration to set expectations: "Features we ship this sprint will impact revenue in 3 weeks."

Weak Correlation (<0.3)

Shipping velocity doesn't predict business outcomes. This isn't necessarily bad - it might mean your product is mature and growth is driven by sales or marketing rather than new features. But if you're a startup counting on product-led growth, a weak correlation here is a warning sign.

Negative Correlation

Rare but concerning. If shipping more correlates with declining metrics, you might be introducing instability, confusing the UX with too many changes, or shipping features that complicate the product. Investigate which specific releases preceded metric declines.

Adding Context With Annotations

Mark specific events on your charts:

• Major feature launches: "Shipped collaboration feature"
• Infrastructure changes: "Migrated to new database"
• Team changes: "Hired 2 new engineers"
• Incidents: "3-hour downtime"

Over months, annotations create a narrative that explains the correlation patterns. You can see at a glance which launches drove growth and which caused problems.

For Engineering Leaders

This data is powerful in planning conversations:

• Sprint planning: "Features in the collaboration category have a 0.7 correlation with signups. Let's prioritize that over the admin dashboard redesign."
• Hiring justification: "Shipping velocity correlates with MRR growth at 0.65. Adding two engineers should accelerate revenue."
• Technical debt arguments: "Bug fix releases correlate with 15% churn reduction. Allocating 20% of sprint capacity to stability is directly protecting revenue."

Get Started

Start a free trial and connect your GitHub repo alongside your Stripe or analytics data. See whether your engineering effort is actually driving your business forward.