How to test your internet connection before streaming an event

Test your internet connection at the venue, on the equipment and network you'll actually use, then run a rehearsal through the streaming service your audience will watch. Check upload speed, connection stability and the finished viewer experience. A fast speed test alone doesn't prove you can deliver a paid live event.

So you've sold online tickets, the speakers are ready, and the venue says its internet is excellent. Until you ask whether anyone has streamed your actual programme through that connection while the building is busy.

The first thing you want to do is turn "excellent internet" into something you can test. You need an agreed stream setting, a connection your crew can use, a rehearsal that exposes problems and a recovery plan that somebody has practised. This guide walks you through that work, including what to ask venue IT, how to read the results and when to change the plan.

Start with the stream you're promising buyers

Before opening a speed test, write down what you're delivering. A paid conference with readable slides and audience questions has different demands from a concert with constant movement. A second simultaneous stage adds another outgoing feed. A remote presenter adds a conversation that has to work in both directions.

Ask your production supplier for the proposed picture resolution, frame rate, video bitrate and audio bitrate. Resolution describes the picture's dimensions. Frame rate describes how many pictures appear each second. Bitrate is the amount of data the stream sends each second. You don't need to become a broadcast engineer, but you do need the supplier to explain its plan in these terms.

Next, confirm where the feed goes. Does the venue send one stream to a service that distributes it, or does the production computer send separate streams to several destinations? Those arrangements place different demands on the venue connection. Get the setup written down before you calculate anything.

Don't choose the highest setting simply because the camera supports it. Choose the setting that delivers what buyers paid to see. Small text may need a clearer slide feed. Fast movement may need different settings from a seated interview. Have the supplier demonstrate the difficult part of your programme rather than making the decision from a camera specification.

Ask about the approved fallback too. If the connection deteriorates, can the crew reduce picture quality while keeping speech clear and slides readable? Will the streaming service accept the changed settings? Decide this during preparation. A setting that works for a talking head may make a practical demonstration useless.

Include the audience access promise in the brief. A private paid stream needs more than a video that technically reaches a server. Buyers have to reach the right page, sign in where required and watch on supported devices. Your connection test should eventually include that whole journey.

If you're still deciding how the physical and online experiences fit together, start with our guide to planning a paid hybrid event. Here, the job is narrower. Prove that your chosen connection can deliver the agreed broadcast.

Ask venue IT what you're actually getting

"Wi-Fi included" isn't enough information. Get the person responsible for the network into the conversation early. A venue salesperson may know which package you've booked without knowing how the production connection works.

Send a practical request. "We plan to broadcast this programme using the attached streaming settings. Which wired connection can our crew use in the production position? What upload capacity is available to us, what else shares it, and when can we test it with your IT team?"

Ask whether the quoted speed describes the building's internet service or capacity allocated to your production equipment. The whole building may have a large connection, yet your room may share a smaller allowance with another event. You need the answer for your production position during your booking.

Find out what guests, exhibitors, payment devices and venue staff will use. Keeping production on a separate network can help the venue control traffic, but a different network name doesn't prove it has a separate internet connection. Have IT explain which resources remain shared and how it will protect the broadcast when attendance rises.

Check access rules before arrival. Your equipment may need registration or specific permission to reach the streaming service. A guest login page can interrupt an unattended connection. Ask how long access lasts, whether it renews during your programme and whether your actual streaming setup is permitted.

Confirm the cable route, available sockets and who supplies the network adapter. A wired outlet across the room doesn't help if the crew cannot safely reach it. Include this in the production plan, alongside camera positions and audio connections.

Get an event contact and a way to reach them without relying on the network you're troubleshooting. Ask what support is available during rehearsal, live hours and any evening sessions. "Our IT person works weekdays" is a problem if your paid stream starts on Saturday night.

Make the commercial responsibility clear. Who orders an upgraded connection if the test fails? Who pays for it, who approves it, and when is the final decision due? You want room to fix the problem before the event, not a surprise charge during load-in.

Our guide to choosing a hybrid event venue covers the wider booking decision. For the connection itself, keep asking until the venue can describe the actual service, access and support you're buying.

Test on the actual production connection

Use the computer or hardware encoder that will send the broadcast. An encoder is the device or software that turns your camera and audio feeds into a stream. Plug it into the planned connection, in the planned position, with the adapter and cable the crew will use.

Testing a phone beside reception tells you about that phone and that location. It doesn't test your production laptop backstage. The same applies to a crew member's home speed test or a screenshot from the venue's office. Useful context, perhaps. Approval for your stream, no.

Start with a quiet baseline. Close unnecessary uploads and downloads on the test device so you know what you're measuring. Record whether you used Ethernet or Wi-Fi, which network you joined, where the device sat and when the test ran. Keep a screenshot or export alongside those notes.

OBS, the open source broadcasting software project, recommends a wired connection for streaming because Wi-Fi can be unstable. Prefer Ethernet where the venue and production setup allow it. Still test it. A cable removes one wireless dependency, but it doesn't prove the building's internet service or the route to your stream destination is healthy.

If Wi-Fi is your only practical option, test in the final production position. Ask venue IT to approve the arrangement and consider whether moving the production desk would improve it. Don't assume an empty room's wireless performance will survive an audience with phones, exhibitors and another event next door.

Run the baseline before sending your test stream. A speed test deliberately uses the connection, so running it during a broadcast can compete with the broadcast you're trying to assess. Later, if IT wants to examine behaviour under load, make that a planned test with a clear purpose.

Use the same test method across comparisons. If you change devices, test services and locations at once, you won't know why the results changed. You can use another test service to investigate a surprising result, but record the change and follow it with an actual streaming rehearsal.

Repeat after any material setup change. A replacement adapter, different room or new network allocation means you're testing a different arrangement. Keep the latest approved setup easy for the crew to identify.

Read upload speed before the big download number

Your broadcast sends data out of the venue. Upload speed is therefore the first speed-test result to inspect. Download speed matters for incoming remote speakers, production tools and other traffic, but a large download result doesn't tell you whether you can send your chosen feed reliably.

Keep the units consistent. Mbps means megabits per second. Encoder settings may use Kbps, kilobits per second. For a worked example, a setting of 6,000 Kbps equals 6 Mbps. Don't confuse either with megabytes used for file sizes and data allowances.

Add up the traffic you're deliberately sending. In a fictional setup, video uses 6 Mbps and audio uses 0.128 Mbps, so the media feed uses 6.128 Mbps before other network traffic and delivery overhead. That arithmetic describes this example, not a recommended setting for every event.

The connection needs room beyond the planned media traffic. How much room depends on the setup, other users and the stability you observe. Ask the supplier and venue IT to agree a working allowance for your event. Don't treat a universal multiplier found online as proof that your stream will work.

Use your delivery service's current requirements. YouTube's live encoder guidance, checked in October 2026, makes recommendations by resolution, frame rate and codec. A codec is the method used to compress video. Its figures are settings for sending video to YouTube, not a complete upload requirement for your venue.

For example, YouTube currently recommends 14 Mbps for H.264 video at 1080p and 30 frames per second. That doesn't mean a speed test showing 14 Mbps approves the connection. Audio, other traffic and variation still matter. Nor should you copy that setting into a different streaming service without checking its guidance.

Avoid counting viewers as separate uploads when your delivery service distributes one incoming feed. If you send one feed to the service, adding online viewers doesn't automatically create another full feed from your venue for each person. Confirm the distribution arrangement with the supplier. Separate outgoing destinations and simultaneous stages are a different calculation.

Read repeated results together. A connection that produces an impressive peak and then collapses during the next test deserves investigation. Your event needs the broadcast to keep arriving, including during its busiest sessions. Save the range you observed and the conditions, rather than reporting only the best screenshot.

Check what happens when the connection gets busy

Speed is only part of the picture. A connection can move a lot of data and still become awkward for live production when traffic competes. You want to know whether the network behaves consistently under the conditions your event will create.

Cloudflare's explanation of its speed test describes upload and download measurements alongside latency, jitter and packet loss. Latency is the time data takes to travel and return. Jitter describes variation in that timing. Packet loss means some pieces of data don't reach their destination.

Cloudflare also measures loaded latency, which is the round-trip time while the connection is busy. That helps distinguish a quiet network from one struggling while it moves traffic. The result describes the test's route and conditions. It isn't a guarantee about your streaming destination.

You don't need to invent pass marks for every metric. Ask the production supplier which results concern it for the proposed workflow, then investigate those concerns with IT. A one-way broadcast and a remote presenter conversation may react differently to the same network behaviour.

Build a realistic busy test with the venue. Include the production tools you intend to run, any incoming remote call and the other traffic your event genuinely needs. Ask IT how guest use and neighbouring rooms will affect the resources your production uses.

Keep the test controlled. Don't tell every crew member to download large files without warning and call that realism. You could disrupt another customer's event or create conditions unrelated to your own. Agree the load, the time and who can stop the test.

If the busy test performs badly, ask what changed. Did production lose its reserved capacity? Did a scheduled upload start? Was the room using a different wireless connection? Did the incoming speaker's call fail while the outgoing stream stayed healthy? These observations help the right person fix the right problem.

Remember what you couldn't reproduce. If guest attendance isn't available during rehearsal, record that limit and ask IT how it will manage audience traffic. A sensible test report includes the unknowns. Pretending an empty building recreated doors-open conditions helps nobody.

Run a rehearsal through the real streaming service

Now send the agreed stream to the actual destination. Use its test or private setup where available and make sure you're not exposing paid content or access credentials. The production supplier should know how to rehearse without accidentally broadcasting to the public.

Use representative material. Include speech, music where your programme has it, movement, slides and any live demonstrations. A static holding screen gives the audience almost nothing to assess. YouTube explicitly advises testing with audio and movement similar to the planned stream.

Have somebody watch on a separate internet connection. A preview on the production computer tells you what the computer is doing, while an outside viewer tests what reaches the audience. Keep that person away from the venue network so a local fault doesn't confuse both sides of the test.

Ask the viewer to check practical details. Can they understand speech, read the slide text and follow a demonstration? Does playback stop? Does sound drift away from the picture? Do they have to keep refreshing? Record the time of each problem so the crew can compare it with production logs.

The supplier should watch its outgoing stream status and the service's reception dashboard. Compare both with the viewer's observations. A clean camera preview cannot settle a complaint about buffering, and a warning on the service dashboard shouldn't be ignored because one viewer happens to be watching smoothly.

Rehearse for long enough to include the difficult transitions in your programme. Keep the equipment running through an interval and the return to a session. The point is to expose the working conditions, rather than chase a particular test duration that sounds official.

Include the paid access journey. Use an appropriate test account and confirm that joining instructions reach the intended viewing page. Check any login and ticket validation your delivery arrangement requires. A healthy broadcast behind a broken joining link is still a failed experience for the buyer.

If your event includes remote speakers, rehearse them on their own planned connections. A strong venue upload cannot fix a presenter whose audio keeps dropping at home. Agree an alternative for each critical speaker, such as a prepared recording or a different joining location, and check that you can use it.

Our hybrid event rehearsal checklist helps you connect this network test with the room programme. Keep one rehearsal record so production, the host and audience support all know what passed and what remains unresolved.

Separate a network fault from a production fault

When the picture breaks up, "the internet is bad" is an understandable first reaction. It isn't a diagnosis. Start with where the problem appears, then change one thing at a time.

If the camera preview or local recording already looks wrong, inspect the camera, audio routing and production device. If the local output is healthy but the receiving service reports missing data, investigate the outgoing connection and route. If the service looks healthy while one viewer struggles, check that viewer's device and connection.

YouTube's live-stream troubleshooting guide follows that distinction. It separates a single viewer's error from problems across multiple connections and asks operators to inspect the encoder before investigating outbound internet. Use that logic with your chosen service's own support instructions.

Ask the supplier to distinguish network dropped frames from frames the production computer cannot render or encode. Both can produce unpleasant video, but they point to different fixes. Buying more bandwidth won't make an overloaded computer process video faster.

OBS describes network dropped frames as a sign that the connection to the receiving server is unstable or cannot keep up with the configured bitrate. Its guide also discusses changing the receiving server, reducing bitrate and checking interfering software. Those are diagnostic options for the technician, not a reason to alter every setting at once.

Write down the symptom before touching the setup. For example, "Outside viewer froze during slide change; venue preview remained smooth; receiving service reported connection problems." That gives the supplier something more useful than "stream failed" when it reviews the logs.

Try the smallest justified change and repeat the same test material. If swapping a cable fixes the issue, confirm the result through the actual destination. If lowering the video setting works, check that slides and demonstrations still meet the ticket promise.

Leave venue security changes to the authorised people. If the supplier suspects a blocked connection or interfering network policy, ask IT to investigate the specific requirement. Turning off protections casually can create another problem without proving the stream will work.

Prove that your backup can recover the broadcast

A backup connection becomes useful when the crew can switch to it and the audience can continue watching. A spare hotspot in a bag hasn't passed that test.

Ask what failure the backup covers. Another connection through the same building equipment may help with some faults while leaving a shared dependency. A mobile service introduces different dependencies, including coverage, congestion, power and its data plan. Have the supplier explain which risks remain.

Test the backup inside the actual production area. Don't accept a strong phone signal outside the venue as proof of indoor upload performance. Use the planned device, stream settings and receiving service. Include the fallback quality if the backup cannot support the primary setting.

Check the data allowance against your programme and rehearsal time. Have the supplier calculate expected consumption from the agreed settings, then account for additional traffic and the provider's charging rules. An unlimited-looking plan may still have restrictions you need to understand. Read the actual terms rather than guessing.

Practise the changeover with the supplier. Confirm whether it happens automatically or requires someone to act, whether the receiving service keeps the same event running and whether viewers must refresh or follow another link. Watch from outside the venue while you do it.

Record the interruption and what recovered. Can viewers hear the speaker again? Are captions still present? Does the recording continue? If the recovery changes the audience experience, your host and support team need to know what to say.

Keep a local recording where the production plan supports it. A recording can preserve material for a replay when delivery fails, but it doesn't give online buyers the live experience they purchased. Include recovery of the live broadcast and preservation of the content as separate decisions.

Decide who can call a pause and who tells the audience. The person monitoring the connection should have a direct way to reach the show caller or host. Waiting for a chain of messages while a speaker continues creates more missed content and more work afterwards.

Write an approval record your crew can use

Give the connection a clear outcome. It passed for the agreed setup, it passed with stated conditions, or it didn't pass. "Probably fine" isn't an outcome you can plan a paid broadcast around.

Keep a short record with these fields:

• Venue, room, production position and test date.

• Connection, device, cable or adapter and named venue IT contact.

• Streaming service, video and audio settings, and simultaneous feeds.

• Speed-test results and the quiet or busy conditions used.

• Actual rehearsal results, outside viewer observations and unresolved faults.

• Backup test result, approved fallback and changeover responsibility.

• Person approving the setup and the conditions that require another test.

Write conditions in words someone can act on. "Approved only with the tested wired connection and the agreed production allocation" is useful. "Network looked good" leaves the crew guessing which arrangement you assessed.

Treat a failed test as a production decision with a deadline. Your options may include fixing the connection, simplifying the stream, changing rooms or bringing in a different delivery arrangement. Ask the supplier to price and demonstrate the realistic options. Compare them with the revenue and service promise at stake.

Don't sell an untested workaround as solved. If the venue offers an upgraded connection, repeat the test on that connection. If the supplier proposes a lower setting, rehearse the slides and movement at that setting. Each solution needs evidence that it delivers your programme.

Share the approved record with the people who can accidentally change the setup. The venue must know which outlet production needs. The crew must know which settings passed. The host must know the recovery cue. Audience support must know where the viewer joins.

Keep passwords and stream keys out of widely shared notes. Store them through the production team's appropriate access process and make sure the authorised operator can retrieve them. A useful handover explains the arrangement without publishing access to the broadcast.

Recheck before doors and monitor during the event

An earlier rehearsal gives you a tested plan. Event day tells you whether that plan still exists. Verify the room, connection, equipment and settings before the audience arrives, while there's time to correct a substitution.

Confirm that the crew is on the approved network. Check that the venue hasn't moved production to a guest connection or reassigned the outlet. Ask whether another event or maintenance work has changed the shared network conditions.

Run your final short broadcast check with an outside viewer, then stop unnecessary tests before the live programme. Confirm speech and slides, receiving-service health and the audience joining page. Test the communication route between production, the host and support as well.

Assign somebody to monitor the broadcast throughout the programme. Looking at the camera output while switching shots isn't the same as watching what the audience receives. Give the monitor permission to report faults immediately and a clear person who acts on them.

Avoid starting large file transfers on the production connection during live sessions. Keep crew uploads and other optional work within the arrangements agreed with IT. If footage has to leave during the event, include that requirement in the tested plan rather than discovering it mid-session.

If the stream fails, use the rehearsed response. Pause where appropriate, tell viewers what you know and give them a next update. Don't promise a restart time until production has evidence for it. Support can collect reports without asking every buyer to repeat the same troubleshooting steps.

Prepare the attendee message before you need it. With Loopyah's attendee email tools, you can send event updates to ticket holders and test the message first. Use that to keep buyers informed when joining instructions or delivery plans change. Your production team and streaming service still own restoring the broadcast.

Afterwards, keep the incident times, logs and viewer reports with the test record. Review what failed and whether the recovery worked before the next event. Good preparation gets more useful when you carry the specific lessons forward.

Give buyers a way to report a problem

Make audience support part of the test. Give your rehearsal viewer the same help route buyers will receive, then ask them to report a playback problem. Does the message reach someone who can act, or disappear into an inbox nobody watches during the show?

A useful report says which session the person was watching, roughly when the fault happened and whether they could hear audio. Ask which device and connection they used where that helps diagnosis. Keep the request short. Someone missing a paid session should not have to complete a technical questionnaire before you acknowledge them.

Agree how support will recognise a wider fault. If several people report the same interruption at the same moment, send that information to production promptly. If one person cannot join while outside monitors are watching normally, help them check the access instructions and supported viewing arrangement.

Use the rehearsal to check those handoffs too. Your connection can pass every technical test and still leave the audience stranded when nobody owns the support messages. A named person, a working contact route and a rehearsed escalation make the test useful during the event.

What should you approve before going live?

Approve the complete tested arrangement. You need the actual production connection, enough stable upload capacity for your agreed feeds, a successful rehearsal through the chosen service and a backup the crew can operate. The outside viewer must be able to use the access journey and follow the programme.

If one part hasn't passed, name it and resolve it before calling the broadcast ready. Your buyers paid to experience the event. The best evidence you can give yourself is a rehearsal that delivers that experience, under conditions close enough to the real show to expose the problems while you still have time to fix them.