Primary tool

Sort the Bricks Pace Calculator

Turn your brick count and elapsed time into a clear personal pace, then estimate a target at the same speed.

Official fastest-time leaderboards exist in Sort the Bricks. This calculator measures the player's own pace without claiming a rank or record benchmark.

PACE RESULTS

Your entered pace

Enter a completed run to see bricks per minute and seconds per brick. A target brick count also unlocks a time estimate.

Formula: bricks ÷ elapsed seconds × 60.

Target time uses target bricks × seconds per brick. Calculations keep full precision until display.

How the math works

Two rates and one projection, from numbers only you can see

Sort the Bricks! publishes no pace statistics, so this tool computes rates from your own run instead of quoting invented benchmarks.

Bricks per minute

bricks sorted ÷ elapsed seconds × 60. This is the headline rate: what you would sort if the run went on for another minute at the same tempo.

Seconds per brick

elapsed seconds ÷ bricks sorted. The same run flipped upside down — many players find “about three-quarters of a second per brick” easier to feel than “80 per minute”.

Target time

target bricks × seconds per brick. Optional: leave the target field empty and the tool stops at the two rates.

Worked example

A run, calculated end to end

The bricks and minutes here are an illustration of the arithmetic — not a game-documented benchmark.

You finish a run with 400 bricks sorted in 5 minutes flat (300 seconds).
Bricks per minute: 400 ÷ 300 × 60 = 80.0 bricks/min.
Seconds per brick: 300 ÷ 400 = 0.75 s.
Target 1,200 bricks (a new full set): 1,200 × 0.75 = 900 s → 15m 0s at the same pace.
Next run you sort 440 in 5 minutes — 88/min, 0.68 s per brick — and the same 1,200-brick target drops to about 13m 38s. That 10% pace gain is exactly the kind of change a single rate hides and this tool exposes.

Interpreting your result

What a pace number is good for in this game

Sort the Bricks! is a fastest-time game — the official description's promise is leaderboards for sorting speed — so a personal pace is the training metric, even though no official benchmark is published.

Compare runs, not people

Server conditions, brick layouts, and upgrades differ, so a rate from someone else's video proves nothing about your run. The number to beat is your previous run's rate under the same conditions.

Mind the session length

Community trackers measured a typical visit at about 8 minutes (BloxBunny, 28-day window checked 2026-10-09). A pace you can hold for five minutes is more relevant than a burst you cannot repeat — measure full runs, not highlight moments.

Population context, dated

Roblox's API showed 257 players at the 2026-10-09 sample (10,701,001 lifetime visits, 83% positive votes). Leaderboard competition is real but the pond is small — week-average population was 110 per BloxBunny.

When to re-measure

After any upgrade purchase, ability unlock, or game update. The experience last changed on September 22, 2026 per Roblox's API, and updates can silently change the loop your old pace was measured against.

Reference

Player-population facts behind the notes

Each row names its source and the date it was checked. Samples move — the official API snapshot is the baseline.

Metric	Value	Source	Note
Concurrent players	257 at the 2026-10-09 sample; 110 average over a prior tracked week	Analytics tracker	BloxBunny samples the Roblox public API hourly. Its week-average was down 69% on the week before, so population swings hard.
Lifetime visits	10,701,001	Official	Roblox public API. A third-party tracker (Bloxstack) showed a much smaller figure (3.1M) in the same week — trust the official API.
Favorites	92,177 lifetime; 6.9 new favorites per 1,000 visits over a tracked 28-day window	Official + Analytics tracker	Lifetime count from the Roblox API; the per-1,000 rate is BloxBunny's 28-day window. For reference, that puts it in the 67th percentile of live Adventure games on BloxBunny.
Rating	4,694 up / 991 down votes ≈ 83% positive	Official	Roblox public votes API, checked 2026-10-09. Trackers showed 82–85% in tracked weeks.
Time per visit	8 minutes (player-hours ÷ visits, 28-day window)	Analytics tracker	BloxBunny's measured session length — the frame a sorting run usually has to fit in.
Visit pace	71.8K visits per day over the last 27 days (vs a ~138K/day lifetime average since July 19)	Analytics tracker	Both numbers are derived arithmetic: BloxBunny's 27-day delta, and lifetime visits ÷ days since creation. The direction matters: discovery-driven traffic has cooled since launch.
Servers	16 players per server; ~15 live servers at the 2026-10-09 sample	Official + Analytics tracker	Server size from the Roblox API; live-server estimate from BloxBunny at the same CCU.

FAQ

Calculator questions

How is sorting pace calculated?

Bricks per minute equals bricks sorted divided by elapsed minutes.

Is the target time an in-game promise?

No. It is a personal estimate that assumes you maintain the pace entered from your own run.

What pace should I aim for in Sort the Bricks?

There is no published pace benchmark: the developer publishes no stat tables, and leaderboard times are not shown outside the game. The useful comparison is your own — record a run, calculate it here, then beat your own bricks-per-minute. Community videos like OTTER EXTENDED's leaderboard chase (September 2026) show top players grinding the same loop one run at a time.

Does a gamepass change the math?

Only if it changes how many bricks you sort per minute — and the Store descriptions checked on August 14, 2026 did not explain what any pass does, so no pass effect is built into this calculator. If you own a pass, time your runs with it and enter what you actually observe; the calculator treats your inputs as the truth.

Why does the target time assume constant pace?

That is how the estimate stays honest. target bricks × seconds per brick projects a finish line if you keep sorting exactly as you did during the measured run. Real runs drift — upgrades kick in, drawers fill, focus dips — so treat the estimate as a planning number, not a stopwatch promise.