How to create a screen recording to show a website’s robot loop

When a website repeatedly shows a human-verification screen, returns to the same page, or refreshes the challenge, you are seeing a robot loop. A useful recording captures that sequence as it happens rather than relying on words such as “stuck”. The aim is a time-stamped record of what a visitor actually encountered.

Keep the recording focused on the full address bar, the visible prompt, redirects and at least one complete return to the challenge. Brief narration can help, although silence is acceptable when the screen is clear. A continuous take usually explains the problem better than several edited clips because timing and repeated attempts are the evidence that matters.

Australian conditions can affect what you capture. A visitor may use NBN broadband, fixed-line Wi-Fi, 4G or 5G, then compare that with a Telstra, Optus or Vodafone Australia hotspot. Sydney, Melbourne and Brisbane use different time zones, and daylight saving changes some timestamps, so note the date, local time and time zone.

Use Australian English if you narrate, and report observations without staging them. Someone saying “hang tight” while the page repeats itself is describing what happened, not admitting fault. A small business may rely on a shared IT provider, so the recording might belong with that provider rather than the site owner. Keep unrelated tabs and customer details out of frame.

Understand what the recording must prove

A robot loop is not automatically proof of a blocked account or a broken website. It might be a challenge that has not completed, a session that resets, or a browser-security mismatch. Record what appears rather than assigning a cause. This distinction helps an Australian support team compare your visit with other sessions.

Because the page currently visible offers only human confirmation and no substantive business content, concentrate on repetition: wording, transitions, timing and the conditions that bring the loop back. The psychology of robot checks explains why repeated prompts can feel personal or frustrating. Those reactions are normal, but the technical description should remain factual.

Plan a controlled test

Start with one ordinary route to the affected page. Open the exact URL in the browser you normally use, place the cursor where the visitor would see it, and begin recording before navigating. Try the action once and let it finish; do not repeatedly reload or submit the challenge, since extra attempts can create rate limits and muddy the evidence.

Record the conditions around the visit: device, operating system, browser and version, network type, and whether you were signed in. A private window can produce different behaviour from a normal profile, so use the same setup a real customer would use. Include the page loading for several seconds before and after the loop so the sequence is not left to interpretation.

Configure browser and privacy

Use a normal browsing profile and close tabs containing email, banking, customer records, passwords or payment details. If you must sign in to reproduce the issue, complete that step before recording. Keep the address bar visible, use a readable zoom level, and turn off notifications that could expose personal information or cover the challenge.

A screen recording can contain more than the visible page. Audio may capture your voice, another person’s voice, account identifiers or support chat details. For personal information covered by the Privacy Act 1988 and the Australian Privacy Principles, collect only what is needed for the report and avoid unnecessary customer data. Passwords, one-time codes and full card details should never appear.

If you blur, crop or annotate the video, work on a copy and keep the original untouched. Make every edit obvious rather than altering the meaning of the sequence. A simple caption such as “second challenge, 00:42” helps a reviewer, while a missing address bar or unexplained jump can weaken the evidence.

Record on Windows, macOS, or mobile

On Windows, open Snipping Tool, choose the screen-recording control, select the browser window and record the attempt; Windows 11 also offers a microphone toggle for optional narration. On a Mac, press Shift-Command-5, select a window or region, enable the microphone only if needed, and click the record button. Keep the whole browser in frame, including the address bar.

On Android, use the system screen recorder, usually through the notification shade, and on iPhone, add Screen Recording to Control Center before starting it. Start before opening the page, stop only after the repeated screen has settled, and save the original file. A second pass can capture a clean view if the first includes an accidental notification.

Practice once with a harmless page and confirm that the file plays on the device you will use to send it. Do not narrate assumptions such as “the server is down”; say what you can see, such as “the verification page returned after the page began loading”. Objective wording keeps the recording useful.

Compare networks without chasing a workaround

First reproduce the loop on the original connection. Then, if useful, make one controlled comparison on a different network. For a phone hotspot test, follow the explanation of using a phone hotspot to isolate the connection. The test shows whether behaviour changes by carrier route, DNS, IPv4 or IPv6 path, Wi-Fi network or browser session.

Switching networks is a diagnostic comparison, not a guarantee that a check will pass, and repeated retries can trigger further controls. Keep other conditions constant, including the same browser and page URL. A phone hotspot may also expose a different mobile coverage area, so describe it as a network change rather than proof that one provider is responsible.

Never record another person’s hotspot session without permission, and do not include the hotspot phone number in the clip. If the challenge behaves differently, keep both clips unedited and label them by connection type and time. That gives support a controlled result without turning the recording into an attempt to defeat the security check.

Review the evidence before sending

Review the whole video before sharing it. A live site such as Alwatan Libya can help confirm that the browser can render ordinary pages, but it cannot establish how a different site’s security system behaves. Keep the focus on the affected URL and do not use an unrelated site as a substitute for proof.

Check that each visual claim matches what happened, then use these two short lists as your recording and delivery guide.

Capture details

Delivery checks

Finish with a clear support handoff

Write a short summary beside the clip: when the loop occurred, what you did, what appeared and whether it changed on the second network. Mention any relevant error code exactly as displayed. If the site has no support address, the hosting provider or the small business’s IT provider may be the appropriate place to raise a technical issue.

Attach the original video rather than only a screenshot or a link that may expire. Keep filenames descriptive, such as a date, the affected page and “robot-loop”, and do not add speculation. If an edited version is easier to follow, send both and state which one is original.

The concrete next step is to send the original recording, the completed test summary and a one-sentence description of the repeated challenge to the website’s support or hosting contact.