Recorded as a bug from your own instance. netwatch's manager takes it when work restarts on 25 October.
Definition of done
The cause is found and stated in one plain sentence here: why netwatch shows over 800 ms for console.cloud.google.com while ICMP ping to it is under 35 ms.
Each figure netwatch shows measures what its label says. A figure that includes DNS lookup, connection setup, TLS, redirects or the response body says so in its label, or the measurement is changed to match the label.
From a network where ICMP ping to console.cloud.google.com is under 35 ms, netwatch's latency figure for it is in the same range as a direct measurement of the same thing, such as curl's connect or first-byte time.
A test covers the corrected measurement.
Model: opus-5-5
Recorded as a bug from your own instance. netwatch's manager takes it when work restarts on 25 October.
## Definition of done
- [ ] The cause is found and stated in one plain sentence here: why netwatch shows over 800 ms for `console.cloud.google.com` while ICMP ping to it is under 35 ms.
- [ ] Each figure netwatch shows measures what its label says. A figure that includes DNS lookup, connection setup, TLS, redirects or the response body says so in its label, or the measurement is changed to match the label.
- [ ] From a network where ICMP ping to `console.cloud.google.com` is under 35 ms, netwatch's latency figure for it is in the same range as a direct measurement of the same thing, such as `curl`'s connect or first-byte time.
- [ ] A test covers the corrected measurement.
Model: opus-5-5
Plan. Each figure is the time a no-cors GET from the browser takes until the answer's headers arrive (measureLatency in web/src/main.js). It includes DNS lookup, connection setup and TLS whenever the browser opens a new connection, and the browser follows every redirect first. Several targets answer with a redirect, so their figure times a different host:
https://console.cloud.google.com redirects twice, to the accounts.google.com sign-in page.
https://console.aws.amazon.com redirects to /console/home.
https://api.backblazeb2.com redirects to www.backblaze.com.
Every S3 regional endpoint redirects to https://aws.amazon.com/s3/.
/robots.txt on each of these hosts answers directly, with no redirect.
One worker, one PR into next, after #192 lands, since both change measureLatency:
Check every target with curl, then measure the real page in the containerised headless Chrome that script/frontend-viewport-test uses, and compare.
Give every target that redirects a URL on the same host that answers without a redirect, so the figure for console.cloud.google.com is in the range of curl's first-byte time.
Say plainly in README.md what the figure includes, add a test to test/unit/main.test.js, and state the cause here in one plain sentence.
Model: opus-5-5
Plan. Each figure is the time a `no-cors` GET from the browser takes until the answer's headers arrive (`measureLatency` in `web/src/main.js`). It includes DNS lookup, connection setup and TLS whenever the browser opens a new connection, and the browser follows every redirect first. Several targets answer with a redirect, so their figure times a different host:
- `https://console.cloud.google.com` redirects twice, to the `accounts.google.com` sign-in page.
- `https://console.aws.amazon.com` redirects to `/console/home`.
- `https://api.backblazeb2.com` redirects to `www.backblaze.com`.
- Every S3 regional endpoint redirects to `https://aws.amazon.com/s3/`.
`/robots.txt` on each of these hosts answers directly, with no redirect.
One worker, one PR into `next`, after https://git.eeqj.de/sneak/netwatch/pulls/192 lands, since both change `measureLatency`:
1. Check every target with `curl`, then measure the real page in the containerised headless Chrome that `script/frontend-viewport-test` uses, and compare.
2. Give every target that redirects a URL on the same host that answers without a redirect, so the figure for `console.cloud.google.com` is in the range of `curl`'s first-byte time.
3. Say plainly in `README.md` what the figure includes, add a test to `test/unit/main.test.js`, and state the cause here in one plain sentence.
Model: opus-5-5
The over-800-ms figure did not show up from this host, so what causes it on your network is not found. Here the browser's check of console.cloud.google.com gets Google's 403 answer directly, in ping time plus the time Google's server takes to answer. Google sends the sign-in redirect that curl sees only to requests that do not say they come from another site, and browsers say so. The browser's network panel entry for that check on your network would show what the rest is.
#193 checks each target whose home page redirects at /robots.txt on its own host.
Model: opus-5-5
The over-800-ms figure did not show up from this host, so what causes it on your network is not found. Here the browser's check of `console.cloud.google.com` gets Google's 403 answer directly, in ping time plus the time Google's server takes to answer. Google sends the sign-in redirect that `curl` sees only to requests that do not say they come from another site, and browsers say so. The browser's network panel entry for that check on your network would show what the rest is.
https://git.eeqj.de/sneak/netwatch/pulls/193 checks each target whose home page redirects at `/robots.txt` on its own host.
Model: opus-5-5
The 800 ms does not show from here. From this host, the browser's check of console.cloud.google.com gets Google's 403 answer directly, in about ping time plus Google's time to answer. Google sends the sign-in redirect that curl sees only to requests that do not say they come from another site, and browsers do say so. So the extra time comes from something on your machine or network.
Question: which browser shows the 800 ms, and what does its network panel's Timing tab show for one check of console.cloud.google.com? Its parts (queueing, DNS lookup, initial connection, SSL, waiting for the server) show where the time goes.
Meanwhile, #194 fixes the targets whose home page does redirect. Your instance runs prod, which still adds a ?_cb= query string to every check; next does not.
Model: opus-5-5
The 800 ms does not show from here. From this host, the browser's check of `console.cloud.google.com` gets Google's 403 answer directly, in about ping time plus Google's time to answer. Google sends the sign-in redirect that `curl` sees only to requests that do not say they come from another site, and browsers do say so. So the extra time comes from something on your machine or network.
Question: which browser shows the 800 ms, and what does its network panel's Timing tab show for one check of `console.cloud.google.com`? Its parts (queueing, DNS lookup, initial connection, SSL, waiting for the server) show where the time goes.
Meanwhile, https://git.eeqj.de/sneak/netwatch/issues/194 fixes the targets whose home page does redirect. Your instance runs `prod`, which still adds a `?_cb=` query string to every check; `next` does not.
Model: opus-5-5
clawbot
removed their assignment 2026-10-26 02:42:01 +01:00
sneak
was assigned by clawbot2026-10-26 02:42:01 +01:00
sneak: this ask belongs here, not on the sysadmin tracker (sneak/sysadmin#4 (comment)). It is back with him: say which browser shows the 800 ms, and paste its network panel's Timing tab for one check of console.cloud.google.com (#190 (comment)).
Model: opus-5-5
sneak: this ask belongs here, not on the sysadmin tracker (https://git.eeqj.de/sneak/sysadmin/issues/4#issuecomment-169755). It is back with him: say which browser shows the 800 ms, and paste its network panel's Timing tab for one check of `console.cloud.google.com` (https://git.eeqj.de/sneak/netwatch/issues/190#issuecomment-154905).
Model: opus-5-5
clawbot
removed their assignment 2026-11-06 18:55:55 +01:00
sneak
was assigned by clawbot2026-11-06 18:55:55 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Recorded as a bug from your own instance. netwatch's manager takes it when work restarts on 25 October.
Definition of done
console.cloud.google.comwhile ICMP ping to it is under 35 ms.console.cloud.google.comis under 35 ms, netwatch's latency figure for it is in the same range as a direct measurement of the same thing, such ascurl's connect or first-byte time.Model: opus-5-5
Plan. Each figure is the time a
no-corsGET from the browser takes until the answer's headers arrive (measureLatencyinweb/src/main.js). It includes DNS lookup, connection setup and TLS whenever the browser opens a new connection, and the browser follows every redirect first. Several targets answer with a redirect, so their figure times a different host:https://console.cloud.google.comredirects twice, to theaccounts.google.comsign-in page.https://console.aws.amazon.comredirects to/console/home.https://api.backblazeb2.comredirects towww.backblaze.com.https://aws.amazon.com/s3/./robots.txton each of these hosts answers directly, with no redirect.One worker, one PR into
next, after #192 lands, since both changemeasureLatency:curl, then measure the real page in the containerised headless Chrome thatscript/frontend-viewport-testuses, and compare.console.cloud.google.comis in the range ofcurl's first-byte time.README.mdwhat the figure includes, add a test totest/unit/main.test.js, and state the cause here in one plain sentence.Model: opus-5-5
The over-800-ms figure did not show up from this host, so what causes it on your network is not found. Here the browser's check of
console.cloud.google.comgets Google's 403 answer directly, in ping time plus the time Google's server takes to answer. Google sends the sign-in redirect thatcurlsees only to requests that do not say they come from another site, and browsers say so. The browser's network panel entry for that check on your network would show what the rest is.#193 checks each target whose home page redirects at
/robots.txton its own host.Model: opus-5-5
The 800 ms does not show from here. From this host, the browser's check of
console.cloud.google.comgets Google's 403 answer directly, in about ping time plus Google's time to answer. Google sends the sign-in redirect thatcurlsees only to requests that do not say they come from another site, and browsers do say so. So the extra time comes from something on your machine or network.Question: which browser shows the 800 ms, and what does its network panel's Timing tab show for one check of
console.cloud.google.com? Its parts (queueing, DNS lookup, initial connection, SSL, waiting for the server) show where the time goes.Meanwhile, #194 fixes the targets whose home page does redirect. Your instance runs
prod, which still adds a?_cb=query string to every check;nextdoes not.Model: opus-5-5
clawbot referenced this issue2026-10-26 04:37:33 +01:00
The browser check is now a task on his sysadmin tracker: sneak/sysadmin#4. Its result lands here.
Model: opus-5-5
sneak: this ask belongs here, not on the sysadmin tracker (sneak/sysadmin#4 (comment)). It is back with him: say which browser shows the 800 ms, and paste its network panel's Timing tab for one check of
console.cloud.google.com(#190 (comment)).Model: opus-5-5