Free tools Windows power users keep installed
One-click scans. No signup required.
Use Promise.all() when every request must succeed for the combined result to be useful. Use Promise.allSettled() when requests are independent and you need to inspect every success and failure, including partial results. Both preserve input order; neither cancels unfinished work when another request fails.
How the two methods handle concurrent promises
| Behavior | Promise.all() |
Promise.allSettled() |
|---|---|---|
| When the aggregate fulfills | After every input fulfills. | After every input fulfills or rejects. |
| If an input rejects | The aggregate rejects with the first rejection reason it encounters. | The aggregate still fulfills, with a rejected-outcome record for that input. |
| Fulfilled result shape | An array of fulfillment values. | An array of outcome records: fulfilled records have status: "fulfilled" and value; rejected records have status: "rejected" and reason. |
| Result ordering | Matches input order, not completion order. | Matches input order, not completion order. |
| Typical fit | Required dependencies: any failure makes the combined answer unusable. | Independent work: partial results and individual failures are useful. |
These settlement behaviors are documented in MDN Web Docs’ Promise.all() reference, which also discusses Promise.allSettled().
As an Amazon Associate I earn from qualifying purchases.
Choose Promise.all() when every result is required
For example, if a screen cannot be built correctly without both a user profile and that user’s permissions, treat the pair as one required operation:
const [profile, permissions] = await Promise.all([
fetchProfile(userId),
fetchPermissions(userId),
]);
The returned array places the profile in the first position and permissions in the second, even if the permissions request finishes first. If an input rejects, the await throws the aggregate rejection; catch it at the boundary where you can report the failure or choose a recovery path.
#1 Best Overall
Choose Promise.allSettled() when partial results matter
For independent requests—such as loading several optional panels—a single failure need not hide successful responses. allSettled() waits for every supplied promise to settle, then lets you handle each outcome:
const outcomes = await Promise.allSettled(
urls.map((url) => fetch(url)),
);
for (const outcome of outcomes) {
if (outcome.status === "fulfilled") {
console.log("request succeeded", outcome.value);
} else {
console.error("request failed", outcome.reason);
}
}
Each outcome remains aligned with the corresponding URL’s position in urls. If you need to report failures by URL or another key, retain that association—for example, keep a parallel input list or map each request to a record containing its key and promise.
Rank #2
Remember that promise rejection is not the same as an HTTP error
With fetch(), an HTTP error status such as 404 or 500 generally still produces a fulfilled promise containing a Response. The examples above classify promise settlement, not whether the server returned a successful status. Check response.ok (or the status code) separately if non-2xx responses should count as failures for your application; you can throw on an unacceptable status before aggregating if you want it to become a rejected outcome.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchNeither method starts bare function references
Pass promises, not async functions that have not been called. This invokes fetch() for each URL while building the iterable:
Promise.all(urls.map((url) => fetch(url)));
By contrast, passing function references such as Promise.all([fetch]) does not call them. The functions are ordinary values, not promises, so the aggregate cannot wait for their work. Call each function first, or wrap the call in a function that is invoked when constructing the inputs.
Fail-fast does not mean cancel the other requests
Promise.all() rejects as soon as an input rejection makes the aggregate fail, but requests already in progress continue unless their underlying API is separately cancelled. The aggregate does not return the other requests’ later outcomes. If cancellation is required, use the cancellation support of the request API and coordinate it explicitly; neither combinator is a cancellation mechanism.
Rank #4
Account for slow requests and large batches
- The slowest input sets the wait for
allSettled(). It cannot produce its final array until every input settles. If an operation might hang, use an appropriate timeout or cancellation strategy for that operation. - These methods do not cap concurrency. They aggregate the promises you give them. For a large batch that must limit active requests, use batching or a concurrency pool rather than relying on either combinator.
- Do not confuse early aggregate rejection with stopped work.
Promise.all()attaches handlers to its inputs; repeatedly attaching handlers to long-lived pending promises in a loop is a separate pattern to avoid.
Make the decision by failure policy, not presumed speed
There is no documented speed benchmark here that establishes one method as faster. The practical choice is about what a failure means: if any missing value invalidates the result, use Promise.all(); if successes remain useful and each failure needs its own handling, use Promise.allSettled().
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.




