TL;DR: Median time from send to acceptance was 25.4 hours across 53,142 accepted LinkedIn connection requests, and median time from acceptance to first reply was 31.0 hours.
Across 53,142 accepted LinkedIn connection requests with a usable interval, the median time from send to acceptance was 25.4 hours, 46.7% were accepted within 24 hours and 92.0% within 30 days. Among accepted connections that replied, the median time from acceptance to first reply was 31.0 hours. Platform data
Key Takeaways
- Median time from send to acceptance was 25.37 hours across 53,142 accepted requests with a usable interval.
- 46.71% of accepted requests were accepted within 24 hours, and 92.04% within 30 days.
- The slowest tenth of accepted requests took 587.07 hours or more to accept, upwards of 24 days.
- Median time from acceptance to first reply was 31.01 hours across 12,911 replies with a usable interval.
- Acceptance and first-reply timing follow almost the same curve shape, clustering around one day at the median.
What did we measure?
Acceptance rates are published constantly. Acceptance timing is not published at all, which is odd, because timing is what determines how long a campaign has to run before its numbers mean anything.
Reachium timestamps every connection request when it is sent, when it is accepted, and when the first inbound message arrives. This study reports the two intervals between those three events across requests sent between 8 January 2025 and 6 August 2026.
How was it measured?
Every timestamp in this study comes from requests sent between 8 January 2025 and 6 August 2026, pulled on 6 August 2026.
Dataset window. Every figure covers connection requests sent between 8 January 2025 and 6 August 2026, pulled on 6 August 2026. Both intervals are computed across all sent requests rather than a maturity-restricted subset, because both are already conditional on an outcome having occurred.
Time to acceptance is the interval from the recorded send timestamp to the recorded acceptance timestamp, across 53,142 usable pairs. The dataset contains 53,952 accepted requests; 810 of them carry an acceptance timestamp earlier than their own send timestamp, which cannot yield an interval, and are excluded. That accounts for the difference exactly. Platform data
Time to first reply is the interval from acceptance to the first inbound message, across 12,911 usable pairs. That number is well below the 14,624 requests flagged as having replied, and the gap is worth stating in full rather than leaving a reader to wonder: 1,233 of them have no recorded acceptance at all, and 275 have no reply timestamp. One request falls into both of those groups, so the two exclusions remove 1,507 rather than 1,508, leaving 13,117 carrying both timestamps. Of those, 206 record a reply earlier than the acceptance it belongs to and are excluded, giving 12,911. Platform data
The likely cause of the inverted timestamps is a conversation that already existed before the request, not a measurement fault worth adjusting for. The 1,233 replies without a recorded acceptance are consistent with the same thing. Platform data
Medians and percentiles, not averages. Both distributions have long right tails, and an average would sit somewhere neither typical nor extreme, describing nothing.
Cumulative shares are the proportion of the same denominators falling at or under each threshold. They are shares of requests that were eventually accepted, not of all requests sent. This study says nothing about how likely acceptance is; that is a separate question with a separate denominator.
What did we find?
The interval from request sent to acceptance splits across four percentile bands, measured on 53,142 accepted requests with a usable interval. Platform data
| Percentile | Hours |
|---|---|
| 25th | 10.37 |
| Median | 25.37 |
| 75th | 144.85 |
| 90th | 587.07 |
| Accepted within | Share |
|---|---|
| 1 hour | 1.50% |
| 24 hours | 46.71% |
| 72 hours | 65.97% |
| 7 days | 76.59% |
| 30 days | 92.04% |
The interval from acceptance to first reply splits the same way, measured on 12,911 replies with a usable interval. Platform data
| Percentile | Hours |
|---|---|
| 25th | 6.45 |
| Median | 31.01 |
| 75th | 121.47 |
| 90th | 644.68 |
| Replied within | Share |
|---|---|
| 24 hours | 46.98% |
| 72 hours | 64.63% |
| 7 days | 79.58% |
| 30 days | 90.43% |
What does this mean for teams measuring outreach campaigns?
The distance between the median and the 90th percentile is the whole story. Half of all accepted requests were accepted inside 25.37 hours. The slowest tenth took 587.07 hours or more, which is upwards of 24 days. Both facts are true of the same population, and any single number claiming to describe "how long acceptance takes" is discarding one of them. Platform data
The two curves have almost the same shape. Acceptance and first reply both cluster around the one-day mark at the median, both reach roughly two thirds inside 72 hours, and both leave around 8 to 10% of their eventual total still to arrive after 30 days. Whatever governs the delay appears to be the same thing in both cases, and it looks like ordinary human attention rather than anything specific to connection requests. Platform data
The practical consequence is about measurement rather than tactics. A campaign read at day three is being read at roughly the two-thirds mark of its eventual acceptances, and a campaign read at day seven at roughly three quarters. Neither is the final number. That gap is large enough to reverse a comparison between two campaigns if one is read earlier than the other. Our analysis
Teams who want their own dashboard to read campaigns at the right maturity point can set that up on Reachium's pricing page.
How do you use this in practice?
An SDR deciding whether a batch of requests has failed is usually deciding too early. In this data, 34.03% of eventual acceptances arrived after the 72 hour mark and 23.41% after seven days (both derived from the cumulative table above). A batch that looks weak on day three is, at the rates measured here, 65.97% of the way to its final count. Our analysis
A RevOps lead comparing two campaigns has a harder version of the same problem. If one campaign is measured at day seven and the other at day thirty, the first is being read at 76.59% of its eventual acceptances and the second at 92.04%. That difference alone is enough to make the better campaign look worse, before any real difference between them is considered. Platform data
Anyone setting a follow-up delay is working against the reply curve rather than the acceptance curve. 46.98% of first replies arrived within 24 hours of the connection being accepted, and 20.42% arrived later than seven days (the latter derived from the cumulative table above). The data describes when replies happened by hour and day of week as well as by elapsed time, but it does not say whether a follow-up sent at any particular point caused any of them, and nothing here should be read as identifying a best time to send one. Our analysis Whether a follow-up is worth sending at all is a separate question, answered in our study of LinkedIn follow-ups.
For a worked example on the same platform, read the Carlisle Capital Group case study.
What are the limits of this study?
Truncation, conditional distributions, and platform-side timestamps set the boundaries here.
Truncation at the end of the window. Requests sent close to the 6 August 2026 pull have had less time to be accepted than requests sent a year earlier, so the longest intervals are systematically underrepresented. The 30 day figures are the most affected. The true tail is longer than what is reported here.
These are conditional distributions. Every figure describes requests that were eventually accepted, or accepted connections that eventually replied. Requests never accepted have no interval and are absent entirely. This is a study of how long success takes, not of how often it happens. That is a different question from the reply-rate decline measured across 2025 and 2026, which is about how often, not how fast.
Timestamps are platform-side. Acceptance is recorded when the platform observes it, not when the recipient tapped the button. Any polling delay inflates the shortest intervals, which is the most likely reason only 1.50% register inside one hour. Platform data
The all-sent totals move, the intervals do not. The 53,952 accepted and 14,624 replied figures above describe the dataset as it stood on 6 August 2026. That cohort grows: requests keep being sent, and acceptances keep landing on requests already sent. Anyone re-running this later will get larger totals. The distributions themselves are stable, but the counts are a snapshot rather than a fixed quantity. Platform data
Time zones are not accounted for. All intervals are absolute elapsed time. Two identical behaviours in different time zones produce different intervals, and no local-time normalisation was applied.
Replies are counted, not classified. No sentiment is recorded, so a fast decline and a fast expression of interest are the same event here.
The dataset is concentrated. The largest customer workspace accounts for 21.97% of all requests sent, the largest five for 57.66%, and the largest ten for 76.19%. These timings are weighted toward heavy senders and their audiences. Teams whose own timing looks different from this baseline can talk to the agency team about a review. Platform data
FAQ
How long does it take for a LinkedIn connection request to be accepted?
Median time to acceptance was 25.37 hours across 53,142 accepted requests with a usable interval. 46.71% were accepted within 24 hours, and 92.04% within 30 days.
How long does it take to get a reply after a LinkedIn connection is accepted?
Median time from acceptance to first reply was 31.01 hours across 12,911 replies with a usable interval, a curve that closely tracks the acceptance timing.
How early is too early to judge a LinkedIn outreach campaign?
A campaign read at day three has only reached 65.97% of its eventual acceptances, and one read at day seven only 76.59%. Reading a campaign earlier than that risks judging it before its numbers are final.
Can a team measure its own acceptance and reply timing?
A team can time-stamp its own send, acceptance and reply events the same way this study does. Teams wanting help setting that up can review options on Reachium's pricing page.