Three different upload figures were on file for this campus when the engagement started. The figure on file said 3 gigabits, symmetric. The firewall that had just been retired reported 4 megabits. A speed test from the new gateway measured 945 megabits down and 45 up. Only the last one was true, and the gap between the three is the reason this note exists.
Upload is what a church spends on a Sunday. The livestream rides on it, along with cloud backups, the giving platform, camera uploads, and every phone in the building posting from the service. Download is rarely the constraint. The upload figure is, and it had been reported wrong by a factor of eleven in one direction and by a factor of sixty-seven in the other.
How the reads were taken
On a Sunday in late August 2026 I read the gateway's traffic graph nine times between 08:36 and 12:45 Hawaii time, across two services. Each figure below is the graph's own maximum for its five minute bucket, not the value at the moment I happened to look. That rule exists because I got it wrong first: a reading at 11:53 went into the notes as the day's peak, and the real maximum came at 12:07. The comparison point is the same graph two days earlier, with the building empty, at 9.8 megabits.
| Condition | Peak upload | Of the 45 Mbps ceiling |
|---|---|---|
| Empty building, two days earlier | 9.8 Mbps | 22% |
| First service opens, 08:36 | 11.2 Mbps | 25% |
| First service peak, 09:08 | 14.0 Mbps | 31% |
| Between services, 10:20 | 14.4 Mbps | 32% |
| Second service opens, 11:00 | 16.3 Mbps | 36% |
| Second service, 11:20 | 16.9 Mbps | 38% |
| Peak attendance, 11:50 | 22.1 Mbps | 49% |
| Second service closes, 12:05 to 12:10 | 35.3 Mbps | 78% |
| Building emptying, 12:35 | 11.9 Mbps | 26% |
The peak is at the close, not at peak attendance
At 11:50 the campus had 85 wireless clients attached, the most this site has ever recorded, and upload stood at 22.1 megabits. Fifteen minutes later, as the service closed and the room began to thin out, it reached 35.3. The last minutes of a service ran roughly sixty percent heavier on upload than the middle of the same service with every seat full.
Headcount and traffic are two different curves. Sizing a circuit on the number of people in the room would have missed the peak entirely.
I do not yet know why. The candidates are ordinary: phones uploading what they recorded, the stream encoder and the recording finishing at the same time, the congregation moving from four sanctuary radios to the lobby and the cafe. It is testable, and it is on the list for the next Sunday, but it is not established, so it is written here as a question and not a finding.
One thing that did get established: the building does not empty between services. The between service trough held 75 clients against a first service peak of 78, while average upload through the trough fell to about one megabit. The 14.4 in the table is that window's brief maximum, not its typical level. The people stayed and the traffic left. Capacity planning for this campus cannot assume a reset at 10:00. The load is continuous from before eight until early afternoon, and it peaks twice.
What 78 percent buys, and what it does not
Nothing failed. Packet loss was zero at all nine reads. Round trip latency moved from 56.6 milliseconds at peak attendance to 64.7 at the upload peak and back to 55.3 once the building emptied, which is consistent with latency tracking utilisation on a loaded asymmetric uplink, and three readings are not enough to call it more than consistent. The stream went out. Nobody in the room noticed anything.
What the number buys is a true statement of the margin. At the busiest moment of an ordinary Sunday, the spare upload capacity was 9.7 megabits. YouTube's recommended H.264 bitrates for live encoders, checked on 2026-09-27, are 12 megabits for 1080p at 60 frames, 10 for 1080p at 30, 6 for 720p at 60 and 4 for 720p at 30. A second full-HD stream, a second campus feed, an overflow room, would not have fit. A 720p one would, with 3.7 megabits to spare.
What the number changed
Before the reads, the circuit conversation with leadership was about a firewall that had been wrong by eleven times. That is a story about old equipment, and it invites the reasonable answer that the old equipment is gone now. After the reads it became a single sentence: an ordinary Sunday reaches 78 percent of the real upload figure, measured, at the service close. That is a story about the circuit, and the chart above is the whole argument.
It also settled what not to buy. At no read were the radios the constraint. The sanctuary access points carried two thirds of the wireless clients all morning with no measurable degradation, and one of them held 16 clients on a single radio at peak. A faster access point would have changed nothing on this chart. The recommendation that went forward was a fiber circuit with roughly ten times the upload, and a repeat of the same nine reads on the first Sunday after it is installed.
Method notes
- Every campus figure is observed from the gateway console on the day, recorded in the engagement's change log at the time of the read. The 45 Mbps ceiling is a measured figure from the same gateway, not a plan figure.
- The stream bitrates are YouTube's published recommendations for live encoders, pulled on 2026-09-27. Published figures are dated in this note because they move.
- The empty building baseline is the same graph, same method, two days earlier. It is the only comparator this site has, and inventing an industry one would have been worse than saying so.
- The site is a multi-campus church on Oahu. Its name is withheld pending written consent, and nothing in this note identifies it.
If your Sunday rides a cable circuit, the number to ask for is the upload, measured at the gateway, in the last ten minutes of your busiest service. The figure on the bill is not the one you need.