GitHub activity, linked to your issues.

Merged and open pull requests, cycle time, review latency, commits and throughput, over thirty days, ninety days or a year. Every pull request shows the issue it closes.

Get started Book a walkthrough

GitHub ActivityPR #12ENG-11190Open the issue

PRMerged in 1hno chasing

IssueMoves to doneno updating

AuthorIs an employeeno mapping

SprintPoints landno counting

One piece of work, not two records of it.

Joined upThe pull request knows which issue it closes

A merged PR carries its ticket, so the work in the repository and the work on the board are the same work. Nobody has to reconcile two lists at the end of the sprint.

The screen

Your engineering activity in one view.

Connect once with the GitHub app and the screen fills itself, with the time of the last update shown at the top. Every merged pull request shows the issue it closed, and contributors who are your employees appear by name rather than by handle.

NearSyncProjectsGitHub ActivitySearch, plan and askKAll hubs

GitHub Activity

your-org/platform · synced 57m ago

30d90d12m

PRs merged30.2/wkOpen PRs4Cycle time<1hmedian open to mergeReview latencymedian to 1st reviewCommits1383Recent PRs14

PR throughputmerged per week

Commit volumeper week

Recent pull requests

#14Release: promote staging to main

#13feat(billing): plan change flow and prorationENG-11204

#12fix(search): stop dropping the second filterENG-11190<1h

#11feat(inbox): department scope on the thread list<1h

#10Home screen enhancementsENG-11158<1h

#9chore: split the reporting module<1h

#8feat: custom fields on any record1h

Contributorsby commits

Amina Rahal

1378 commits3 PRs

devbot @devbot

5 commits0 PRs

Every pull request shows the issue it closes.

Linked issues

Open the issue straight from the pull request.

Each pull request is linked to its issue from the start, so nothing needs matching up later.

See the issue number on every merged pull request
See contributors by name when they are your employees
Watch the issue close by itself when the work merges
Sprint points update automatically when linked issues close
See when the data was last updated, and refresh it any time

Visit the sprint board

Pull request #12ENG-11190

ClosesA real issue

AuthorAn employee

ReconcilingNothing

Contributors

On the payrollBy name

Everyone elseBy handle

Mapping neededNone

Synced 57m agofilled by the app webhook, not by anyone pasting a token

The numbers

See how long work waits for review.

Cycle time and review latency over thirty days, ninety days or a year, all from the same data.

See merged and open pull requests, and merges per week
Track the median time from open to merge
Track the median time to a first review
See throughput and commit volume week by week
If there is not enough data for a median yet, you see a dash, never a made-up zero

What the team learns from it

Last 90 days6 numbers

Cycle timeOpen to merge

Commits1,383

Review latencyNo median yet

Three windows

30 daysThis stretch

90 daysThe quarter

12 monthsThe year

A dash, not a zerobecause no data and no time taken are different answers

Contributors

See who is committing and how much of it gets merged.

Everyone who touched the code in the period is listed by commits, with the pull requests they got merged beside it. The names come from your employee records, so you are reading people rather than usernames.

Where the names come from

In this period

Ranked byCommits

Beside itMerged pull requests

Not an employeeTheir username

Matched by the GitHub handle on the employee record

Recent work

See the last pull requests and how long each one took.

The recent list gives you each pull request by number and title, and whether it merged, is still open, or was closed. A merged one carries its own time from opening to merge, so a slow review stands out beside one that took an hour.

Open the issue behind it

Recent pull requests

MergedWith its own time

Still openMarked with a dot

ClosedStill listed

Time from opening to merge, on the line itself

Every repository

Read one set of numbers across all your repositories.

Each repository you track is named at the top, and the merges, commits and review times cover all of them together. A team that splits the front end from the back end still gets one picture of the week.

Where connections live

Tracked repositories

ListedBy name, at the top

The numbersCover all of them

Last updatedShown beside them

One picture of the week, however many repositories you run

Access

Who can do what.

Everyone on the team can see what shipped and open the issue behind any pull request. Connecting a repository affects the whole organisation, so only a small group can do it.

See

See the metrics and recent pull requests.

Jump from a pull request to the issue it closes.

Manage

Refresh the data and change the time window.

Admin

Connect the repository and decide what is tracked.

Admin is the highest role and is not limited by these permissions, so keep it to the few people who genuinely need it.

One pull request, start to finish

A pull request merged in an hour, and the issue closed itself.

The pull request named the issue it was for, and everything else followed on its own. The issue closed, the sprint counted the points, and the author showed up by name. Because your issues and your team already run in NearSync, none of it needed a second tool.

The pull request names the issue it closes, so the two are linked from the start.