Key finding
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.
What we measured
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.
Methodology
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.
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.
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.
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.
The findings
Time from request sent to acceptance, across 53,142 accepted requests with a usable interval:
| 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% |
Time from acceptance to first reply, across 12,911 replies with a usable interval:
| 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 this means
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.
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.
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.
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.
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.
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. 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.
Limitations
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.
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.
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.
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.