Platform access level: Org Admins
Every Diagnostic interview link doubles as a connection tester. If an interviewee says the interview will not load or the voice agent never speaks, you can add a short code to their link to run a self-test that checks their own browser and network against everything the interview needs and shows a pass or fail list they can screenshot. The test never starts or uses up the interview.
1. What the self-test checks
Opening a link with the self-test code runs a series of checks from the interviewee's own browser and network, and reports each one as PASS, FAIL, or UNKNOWN with a plain-English reason. A summary line at the top carries a timestamp and the pass and fail counts, and the whole page is built to be screenshotted.
What is checked | Why it matters |
Arist interview session | The link works and Arist is reachable |
Voice widget script | The in-page voice widget can load, and the interview cannot run without it |
Voice provider API over https | The voice provider is reachable |
Voice call audio over wss | Live call audio can stream |
Widget images and page fonts | The page renders correctly |
Bot protection | Optional, the interview can still run without it |
Microphone | The browser has permission, after the interviewee clicks Check microphone |
2. When to run it
Run the self-test whenever a connection problem is possible, so you have evidence before anyone spends time on it.
An interviewee reports a failure: The interview will not load, the voice agent never speaks, or the page hangs on a spinner.
You suspect the network: A corporate network, VPN, or proxy may be in the way.
Before a launch at a strict-IT organization: Have one or two people run it on the office network as a pre-flight check.
Before reporting an issue to Arist: Attach the screenshot so the cause is clear from the start.
3. Running the self-test
You run the test by adding ?selftest=1 to the end of the interviewee's own interview link and having them open it.
Important: The interviewee must open the test in the same browser and on the same network where the problem happened. Results from home Wi-Fi only tell you about home Wi-Fi, not the office network or VPN where the interview failed.
Take the interviewee's own interview link and add
?selftest=1to the end.Ask them to open that link in the same browser and network where the problem happened.
The checks run automatically and finish within about 15 seconds.
Ask them to click Check microphone and answer the browser's permission prompt.
Ask for a screenshot of the full list, including the summary line at the top.
Note: Running the test never starts, consumes, or affects the interviewee's interview. It still works after the interview window has closed, so you can look into a report after the fact. It does need a real interview link, since a guessed or mistyped URL shows a 404 page instead of the test.
4. Reading the results
The pattern of passes and failures tells you where the problem is. Use the table to translate the screenshot into a next step.
Result on the screenshot | What it means and what to do |
All rows PASS and microphone ok | The network is fine, so the problem is elsewhere. Share the screenshot with your Arist contact. |
Voice provider rows FAIL over https | A firewall or proxy is blocking the voice provider. Ask IT to allow the hosts in the allowlist below. |
Voice provider https PASS but wss FAIL | WebSockets are blocked, so the page loads but call audio cannot stream. Ask IT to allow wss connections to those hosts. |
wss shows UNKNOWN, "Closed before opening" | Usually fine. The test cannot complete a real call without a live interview, so it trusts the matching https row. Only worry if that https row also fails. |
A row says "likely intercepted" | Something on the network, such as an SSL-inspecting proxy or a block page, is answering instead of the real service. This is for IT to resolve. |
Bot protection FAIL | Optional. The interview still runs, so do not hold things up on this alone. |
Fonts FAIL | Mostly cosmetic or a slow first load. Note it, but it rarely blocks an interview on its own. |
Microphone FAIL | A browser or device permission issue, not a network one. "Permission denied" means allow the mic in the browser's site settings, and "No microphone found" means check the hardware or input settings. |
Tip: If IT cannot unblock the network quickly, offer the phone interview instead. It dials the interviewee directly and does not touch their corporate network at all.
5. Sharing results with Arist
When you send a connection problem to Arist, include the details below so it can be resolved without a round of back-and-forth.
The full screenshot, including the summary line, since it carries the timestamp and the pass and fail counts
The interviewee's browser and operating system
Where they were: an office network, a VPN, or home
The interview link
What the interviewee actually experienced, such as "the voice agent never spoke" or "the page never loaded"
6. IT allowlist
When a firewall or proxy is the problem, ask the interviewee's IT team to allow outbound https, and WebSocket (wss) where noted, to the hosts below. The failing rows on the screenshot show IT exactly which of these are blocked.
Host or domain | Allow | Notes |
Your Arist interview domain, shown in the link | https | Required |
| https and wss | The voice provider |
| https | Images and fonts |
| https | Optional, bot protection |
Related articles
Getting Started with Arist Diagnostic
Note: Need help at any point? Reach out to your Arist Customer Success contact, or email [email protected].