Reviews

The dashboard

The dashboard is the first thing you see after signing in. It answers three questions: how much inline reviewed, what is still open, and how your team received what it raised.

Admins see the whole workspace. Everyone else sees the pull requests they opened, so the same page works as a personal view. The page updates as work lands, so there is nothing to refresh.

#Filters

/dashboardOpen in app

Dashboard

Export

24h7d30d90d12mCustomRepos AllLanguage AllAuthor AnyoneIssues All severities

PRs reviewed

128

Findings kept

76%

High-severity fixed

Median review time

1m 52s

Open issues

Spend

$••.••

Needs attention

Everything open across modules, worst first

All 23Review 11CI/CD 6Security 4Runtime 2

HighSecurityPrototype pollution in lodash.mergependral/inline

MediumReviewCache key omits the severity thresholdpendral/inline

Review activity

Pull requests reviewed per day, by triage outcome, with findings posted

VolumeKeptLatencySpend

Finding outcomes

What happened to findings once their PR closed

51 Fixed22 Accepted14 Dismissed5 Rejected2 Ignored

Pull request flow

Median time in each stage, ready to merge · 41 merged, 9 open

4m inline reviewed3h Human review5h Approved6h Merged

Modules

Ordered by how much this workspace uses each one in the period

Security 2 confirmed exposuresCI/CD 94% success rateCoding agents 37 ad-hoc reviewsNot set up Cloud, Compliance

Repositories

Every module's signal, one row per repository, riskiest first

Repository	Reviews	Kept	Open findings	Security	CI success	Merge gate
pendral/inline	96	78%	7	High	93%	Blocks high
pendral/inline-web	32	71%	2	Clear	97%	Report

Spend

Model spend by module in this period

Per PR review

$•.••

Per kept finding

$•.••

PR review budget, this month

$••.•• / $••.••

The workspace overview, filtered to the window you choose.

The bar along the top sets what every card on the page counts. Pick a window, 24h, 7d, 30d, 90d, 12m or Custom, then narrow it with Repos, Language and Issues, which sets a severity floor such as High and above. Admins also get Author.

Each filter you set appears as a chip you can remove on its own, or all at once with Clear all. The filters live in the page address, so copying the link shares the exact view. Export downloads the Repositories table as a CSV.

#Headline figures

The tiles across the top are PRs reviewed, Findings kept, High-severity fixed, Median review time, Open issues and, for admins, Spend. Each compares itself with the previous window of the same length, and its sparkline draws that previous window dashed underneath.

PRs reviewed splits into the ones that got a full pass and the ones triage handled, so you can see the shape of your traffic. Spend shows the cost per pull request review and, when a budget is set, how much of this month's budget is used.

#Needs attention

Needs attention lists everything open across the modules you can see, worst first: review findings, runtime errors, CI failures, security alerts and cloud findings. A tab per source narrows the list. It reads from the same list your coding agents get from inline, so the two never disagree about what is open.

#Review activity

The Review activity chart plots the window day by day, which is where a quiet week or a release-day spike shows up. Switch it between Volume, Kept, Latency and, for admins, Spend.

#Finding outcomes

Finding outcomes is the most useful card on the page. As reviewed pull requests close, inline records what happened to each finding and reports the pattern back to you, headed by the kept rate: the share that was fixed or accepted.

Outcome	What it means
Fixed	The flagged code changed before the pull request merged.
Accepted	Someone agreed with it, usually with a thumbs up.
Dismissed	The thread was resolved without the code changing.
Rejected	Someone disagreed with it, usually with a thumbs down.
Ignored	Nobody responded either way.

Decided vs kept underneath splits those outcomes by Category or by Severity, so you can see that your team acts on security findings and argues with style ones. That is what to look at when you tune Review config.

#Pull request flow

Pull request flow shows how long merged pull requests spend in each stage, from ready for review to inline reviewed, Human review, Approved and Merged. Switch between Median, P75 and P90. Timing is recorded from GitHub as pull requests move, so it fills in from the day recording began.

#Coverage

Admins see Coverage: how many connected repositories inline reviews, how many have a code graph, and how many are Monitored by Security, with a link to enable the rest.

#Modules

Modules has a card for each part of inline your workspace uses, ordered by how much it was used in the window. The two busiest get large cards. Modules on your plan that were never configured share one Not set up tile, and modules outside your plan or your permissions do not appear.

#Repositories

The Repositories table gives one row per repository with Reviews, Kept, Open findings, Security, CI success, Runtime and Merge gate. Click a column heading to sort by it.

#Spend

Admins also see the Spend card, which splits the window's model spend by module and shows Per PR review, Per kept finding and, when a budget is set, PR review budget, this month. Cost and budgets explains those figures and how to set a ceiling.

#Seeing your own pull requests

inline matches pull requests to you by your GitHub identity. Until you link your GitHub account, your dashboard has nothing personal to show, and a Connect your GitHub account card appears with the link to do it. Once linked, the tiles read Your PRs reviewed, and spend never appears.

The link is read-only and one-time. inline reads your username to match pull requests to you, and nothing else.