The page never finishes loading, whatever timeout you set
Ten seconds fails. Forty-five seconds fails identically. The target is not slow — it is never going to be finished, and no timeout will change that.
The symptom. TimeoutError on the initial navigation. You raise
--timeout from 10 s to 45 s. It fails again, in exactly the same way.
That identical failure is the diagnosis: this is not a duration problem.
What Diwall is waiting for
By default, navigation completes on networkidle — 500 ms of network silence.
That is a good default: it means the page has genuinely settled, scripts have
run, content has arrived.
Some targets never go silent. A dashboard refreshing counters, a live statistics panel, a router administration interface polling its own status — they keep talking to the network by design. There is no moment of quiet to wait for, so Diwall waits until the timeout, every time, at any duration.
Change the condition, not the duration
diwall-shot --url http://target.local/ --wait-until load --som --a11y \
--guide-version 1.3
--wait-until load completes when the page’s own load event fires, without
requiring network silence. The same flag exists on diwall-rpa and is
propagated.
A scenario can carry it as a root property, so it stays self-contained — the person who reuses your scenario does not have to know the target’s quirk:
{"url": "http://target.local/", "wait_until": "load", "actions": [...]}
The command line wins over the scenario Unlike boolean options that combine, this one carries a value — and two values do not add up. If both are set, the flag decides.
Which value to use
| Value | Completes on | Use it when |
|---|---|---|
networkidle | 500 ms of network silence | the default — keep it unless it fails |
load | the page’s load event | the target polls continuously |
domcontentloaded | HTML parsed, subresources pending | you need the earliest possible view |
Do not reach for load pre-emptively. The default gives you a page that has
finished arriving; changing it means accepting that some content may still be
in flight when the capture happens. Change it when the default fails, not
before.
How to tell this apart from a slow page
A slow page succeeds if you wait long enough — raising the timeout changes the outcome. A never-idle page fails identically at every duration.
So the test is cheap: run it twice, once at the default and once at a much larger timeout. Same failure, same speed? Change the condition. Different behaviour? You have an ordinary slow target, and the timeout is the right dial.
In short
- Identical failure at 10 s and 45 s = wrong condition, not wrong duration.
--wait-until loadfor targets that poll continuously.- Put it in the scenario so it travels with the target.
- Keep
networkidleeverywhere else.