GitHub Worklog

The GitHub Worklog page shows GitHub activity across your team for a selected period — issue events, pull request events, comments, and merges — aggregated by repository and teammate.

Use it to answer questions like:

  • Which repositories had the most activity this week?
  • Which teammates were active, and on which issues and pull requests?
  • Is review and merge throughput trending up or down across the team?

Getting started

Navigate to Signals → GitHub Worklog in the sidebar. The GitHub data source must be configured and at least one sync must have completed.

Use the date range picker and teammate selector in the header to filter the data. The page updates immediately when filters change.


Summary cards

At the top of the page, summary cards give a quick snapshot of the selected period:

CardWhat it counts
Total updatesNumber of GitHub events across all repositories and teammates
RepositoriesNumber of distinct repositories with activity
Issues & PRsNumber of distinct issues and pull requests that were touched
TeammatesNumber of teammates with at least one event

The page also offers a per-update table view that lists each event with its actor, target (issue or PR), and timestamp, and a daily aggregation view that groups events by date so you can spot busy or quiet days at a glance.


Activity types covered

The Worklog filters the activity stream to the GitHub-specific event types that represent meaningful work:

  • issue_created, issue_closed, issue_reopened, issue_comment
  • pr_created, pr_ready, pr_reviewed, pr_comment, pr_merged, pr_closed

Push and branch events are intentionally excluded from this view — they’re already visible on the Activity page and would dominate the worklog counts. Use the Activity page when you need commit-level detail.


Notes and limitations

  • The Worklog is derived — it does not consume a separate GitHub “worklog” API. It filters the regular activity stream by data source and event type, so only GitHub events reach this page. The underlying activities must have been synced first.
  • Only teammates with GitHub activity in the selected period appear. A teammate with no GitHub account configured never shows up here, even if they are active in Jira or GitLab.
  • GitHub does not provide native time tracking, so there are no “time spent” columns. The page focuses on counts and frequency rather than hours.
  • Chart visualizations parity with the ADO Worklog charts is a planned follow-up; the v1 page ships the table and daily-aggregation views.

  • Issue Hierarchy — parent/child relationships for the issues that appear in the Worklog.
  • Value Stream — per-issue cycle metrics derived from the same activity stream.