← Radar

clickr.pro

What our own request to this host returned, over the last 30 days. Nothing here was tested for weaknesses and nothing was captured from anyone else's traffic.

Not probed

We hold no observation of clickr.pro in this window. That is a fact about our coverage, not about the site.

Incidents we have recorded for this host

1 open now · not live · lags probing by days

Open now

Incident

EGR-ER1R4QZ1

State

Open

Open since

2026-09-11 06:01:13 UTC

Running

52 d

Consecutive scheduled probes

≥3

Newest failing scheduled probe

2026-09-15 05:56:38 UTC

Newest failing status

521

clickr.pro answered our probe with a server error on at least 3 consecutive probes.

Re-checks are switched off on our main platform, which takes the request: it has its on-demand checks of the hosts we report on switched off, and keeps re-checks off while Radar's prober runs again, so the re-check button sends nothing. When re-checks are switched back on, a re-check sends the host one more probe from us, now, and records what it answers: if it answers without a server error the incident closes, and if it still answers with one the incident stays open. Nobody can close an incident by asking — only the probe's answer can. Anyone may ask for a re-check, but only of a host with an open incident here, and each host can be re-checked at most once an hour — and not within an hour of our ordinary probe of it: one hour shared by everyone asking, because the limit is there to protect the host.

An incident opens when a domain answers 5xx — its own server erroring — on 2 probes in a row, and closes when a probe succeeds. A 4xx, a refusal included, is an answer and does not count.

Each record is one thing we measured: the host answered our probe — one request, from one vantage point — with a server error on the stated number of consecutive probes. It says nothing about what anyone else sees from anywhere else.

The status is the HTTP status the host answered our newest failing probe of that run with — 503, say. It is that one response to that one request, not a summary of the run, and not the newest probe's status: a host that has since answered normally still shows the status of the last probe that failed. A record that reads "not recorded" was opened before we began keeping it and has not failed again since; that is an absence of a measurement, not a status of zero. The run is our scheduled probes: a re-check asked for from this page that fails is not added to it — not to the count, not to the newest failing probe, not to its status — and one that gets an answer closes the record.

Hosts we could not reach at all are not listed. Their incidents are recorded separately and not published here, because from one vantage point a host nobody can reach and a host refusing our prober look the same, and naming one as the other would be a false claim about a working site. So this list is a floor: it can only under-count.

Not live: an incident opens only after 2 failing probes in a row and the estate is swept in passes days apart, so a record appears here days after the errors begin, and a close appears only when a later probe succeeds.

All the incidents we have recorded, on the Radar board →