Estimate when a queued pull request will merge
Returns a live estimate for this pull request’s queue entry: when it is expected to merge, when it starts and finishes testing, and how many pull requests it is waiting behind. An entry in pendingFailure instead reports when that failure is expected to resolve (kind: pendingFailureResolution) and which pull requests it is waiting on.
The estimate is computed on each request by simulating the queue forward, so it changes as the queue moves. Read it when the answer is needed rather than in a tight loop: each call runs a fresh simulation, and like the other pull-request reads it is rate-limited per caller. When no estimate can be given — a queue with too little test history, a pull request that is not ready yet, a paused queue — the response says why (status: unavailable, reason).
Not every queue serves estimates yet: one that does not answers 404 ESTIMATE_NOT_ENABLED.
Authorizations
An API key, sent as Authorization: Bearer <key>. An organization admin creates one in the Trunk app under Settings → Developer → API Keys and chooses the merge-queue permissions it holds; a key with none can read merge queues but change nothing. Those permissions scope merge queue only: every key can use the Flaky Tests and Dynamic CI endpoints, including their writes, whatever permissions it holds.
Path Parameters
The pull request's id.
"0f8fad5b-d9cb-469f-a165-70867728950e"
Response
The entry's estimate, or why there is none
- Option 1
- Option 2
A live estimate for a queued pull request, computed by simulating the queue forward from its current state over the queue's recent test history, or why there is none. A point-in-time prediction: a new submission, a priority change or a failure ahead changes it, so read it again when it is needed rather than counting down from one answer.
available "available"
When the public API received the estimate from the merge service; every other instant is relative to it, so each carries that call's latency.
"2026-10-07T15:04:05.000Z"
merge: estimatedAt is when the pull request is expected to merge. pendingFailureResolution: the entry is in pendingFailure, and estimatedAt is when the failure is expected to resolve — by a restart, a bisection, a pass, or a failure — not a merge time.
merge, pendingFailureResolution "merge"
For kind: merge, the median estimate of when the pull request merges: half of comparable entries finish sooner, half later. For kind: pendingFailureResolution, when the failure is expected to resolve — an upper bound, since it waits for every run the failure depends on, while a restart or a passing run behind it can resolve it sooner.
"2026-10-07T15:24:05.000Z"
How far to trust the instant it accompanies. onTrack: a forecast that moves closer as time passes. holding: not counting down, because the queue is waiting on a step it treats as instant (such as a verification run that can start now) or the instant is under a 30-second floor; it does not mean the instant is near. pastTypical: held by a run, this entry's or one ahead of it, that is past its typical time, so the instant is likely an underestimate; on testsFinishAtState the run is this entry's own, so compare against typicalTestDurationSeconds. pastP95: only on testsFinishAtState, this entry's verification run is taking longer than 95% of the queue's recent passing runs.
onTrack, holding, pastTypical, pastP95 "onTrack"
From how much history the queue has, lowered while the entry waits, sits deep in the queue, is held behind a failure, is bisecting, or has a pending failure ahead of it.
low, medium, high "medium"
How many pull requests this one depends on and so must merge behind: a count of blockers, not a queue position. In a graph queue, pull requests in independent lanes are not counted. Past the graph's soft cap, before the pull request is admitted, it counts every pull request in the queue — an upper bound on its blockers.
3
For pendingFailureResolution, the pull requests whose runs the failure is waiting on right now; empty otherwise.
10000Passing tested pull requests in the queue's last 14 days the estimate draws on — one per pull request per verification run, so a passing batch of four counts four.
120
Present while the entry waits for a test slot.
"2026-10-07T15:09:05.000Z"
Present exactly when startsTestingAt is: how far to trust it.
onTrack, holding, pastTypical, pastP95 "onTrack"
Present while the entry waits or tests: when its verification run is expected to finish passing, including expected restarts.
"2026-10-07T15:23:05.000Z"
Present exactly when testsFinishAt is: how far to trust it.
onTrack, holding, pastTypical, pastP95 "onTrack"
The queue's median duration over its recent passing verification runs, in whole seconds rounded down. Absent when the queue has none to report.
900