Status updates that write themselves from your git activity

Aidan Urbina — Mon, 15 Jun 2026 22:44:16 +0000

I've typed the same status update hundreds of times. "Worked on the auth refactor, still going on it, no blockers." Then I'd open the PR I'd literally just pushed and stare at the description I'd already written there, and the commits I'd already named, and think: I just typed all of this. Twice. Why.

We still do async standups, and I think they're useful. But a standup is the wrong place to first learn what your teammates did. By the time you're reading it, the work is hours old and someone retyped it by hand. The "what I did" part already exists. You generated it when you opened the PR and named the commits. Asking a developer to also type it into a separate box is asking them to be a worse version of git log.

So when we built sparQ, an open-source developer-experience suite for teams that live on GitHub, we tried to make one part of this disappear. Not the standup. The status-typing. Its first product, Pulse, is a GitHub-native project management tool, and in it each person's recent activity fills itself in from the work they're already doing, so the standups and updates sit on top of that instead of repeating it.

The mechanism is simple: GitHub webhooks in, status lines out. Everything that turned out to matter was in the details.

The core idea

GitHub already knows what you did, and it'll tell you over a webhook the instant it happens. We subscribe to three event types (push, pull_request, and issues), and the job is to turn that firehose into a feed a human actually wants to read. Push and PR events become a person's current status; issue events drive a separate two-way sync I'll come back to at the end.

That's the whole architecture. The wiring took an afternoon. The judgment calls took the rest of the week, and they're what the rest of this is about.

Can you trust it?

A webhook URL is a public endpoint. Anyone can POST JSON at it, so if you take the payload on faith, I can post activity as you. GitHub signs every delivery with an HMAC of the body, so we verify that signature before doing anything else.

Two non-obvious things bit us here. First, you have to hash the raw request bytes. If you parse the JSON and re-serialize it, your bytes won't match GitHub's and every signature fails. Second, compare the signatures with a constant-time check, not ==:

hmac.compare_digest(expected, signature_header)

A plain string compare returns as soon as two characters differ, which leaks enough timing information to guess the signature byte by byte. It never shows up in testing and it's the first thing a security review flags.

We also let unsigned webhooks through in development and fail closed in production. Local end-to-end testing already means standing up an ngrok tunnel and a real GitHub App; making people also wire up a shared secret before anything works is how you lose them in the first ten minutes.

How fast can you let go of it?

GitHub retries on any non-2xx and is impatient about slow responses, so you never want a database write or an outbound API call sitting between you and your 200. The endpoint does the bare minimum: verify the signature, look up which workspace this installation belongs to, hand the payload to a background worker, and return immediately.

The catch with going async is that the background thread has no request context, so the tenant the event belongs to vanishes unless you carry it across yourself. We capture the workspace id while we still have the request and re-establish it inside the worker. Every multi-tenant background job has some version of this footgun: it runs fine in your single-tenant test and then writes to the wrong customer in production.

What do you say about it?

This is the part I expected to be trivial and wasn't. A raw push payload is not something anyone wants in a feed. The real work is deciding what to throw away.

The output is a single plain line, like Pushed 3 commits to main: handle expired refresh tokens or Opened PR #214: fix token refresh race. Most of the work is throwing things away to get there.

The one that surprised me was merge commits. Merge a PR and GitHub fires the pull_request "merged" event and, separately, a push for the merge commit it generates on your behalf. Honor both and every merge lands in the feed twice. So we sniff out that auto-generated commit and skip the push:

if head_msg.startswith("Merge pull request "):
    return None

PR events have the opposite problem, which is too many of them. synchronize fires on every push to the branch, and then there's labeled, edited, assigned, and a dozen more that nobody would call a status. Only opened, reopened, ready_for_review, and the final merged-or-closed actually say something, so those are the only actions that produce a line. Branch deletes and tag pushes carry no commits at all, so they say nothing either.

The rule underneath all of it: when in doubt, post nothing. An empty feed is fine. A noisy one gets muted, and a muted feed is the same as no feed, except you paid to build it. This part is unglamorous and it's most of what makes the feed feel trustworthy instead of spammy.

Who does it belong to?

GitHub identifies people by a numeric user id; sparQ has its own users. So each person links their GitHub account once, and after that a webhook's actor id resolves to a sparQ member. If there's no mapping, we drop the event on the floor rather than posting it.

That last decision is deliberate. A status feed is about people. "What is Sam up to." So an authorless post isn't a degraded post, it's a category error. Dropping unmapped actors also quietly filters out the noise you'd never want anyway, like Dependabot pushing forty commits with nobody's face on them.

The harder half: keeping two systems honest

Reading activity is one-way and forgiving. The issue sync is two-way, and two-way sync has a failure mode one-way doesn't: the infinite loop.

Close an issue on GitHub and we close the linked task in sparQ. Fine. But closing the task fires sparQ's own "task changed" listener, which wants to push that change back to GitHub, which fires another webhook, which closes the task again. You've built a machine whose only job is to bury GitHub's API in your own echo.

The fix is boring and it works: a flag that marks "this change originated from a sync, don't bounce it back."

_SYNC_IN_PROGRESS[task.id] = True
try:
    Task.resolve(task.id, resolver_id=None, note="Closed via GitHub")
finally:
    _SYNC_IN_PROGRESS.pop(task.id, None)

The outbound listener checks that flag before pushing anything to GitHub and stays quiet when it's set. The resolver_id=None does double duty as a marker that GitHub made the change rather than a person, which keeps the activity log honest about who did what.

What it adds up to

Connect a repo, link your GitHub account once, go write code. Your recent activity fills in by itself, and nobody typed it. It's just true, because it's the same events GitHub already recorded.

We still write standups. They're better now, because nobody spends them reciting what they already did in git. The "what I did" is already on the board, so the update can be the part a machine can't generate: what you're stuck on, what you're planning, what you want a second opinion on.

The lesson I keep relearning is that most "the team needs visibility" problems aren't missing data. The data's there. It's just trapped in a system that won't talk to the one people are looking at. We didn't generate anything new. We listened, threw most of it away, and wrote the survivors as sentences.

If any of this resonated, the repo is at github.com/gosparq/sparq (AGPL v3, self-hostable). Clone it, docker compose up, and connect a repo to watch your feed fill itself in. The GitHub connector with the parts I glossed over lives in pulse/modules/integrations/github/. A ⭐ helps other teams find it, and I'd genuinely like to hear how the "post nothing when in doubt" rule holds up against your team's git habits. Issues and PRs welcome.

DEV Community: Aidan Urbina