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.
Last status
500
Answered
100% of 16 probes
Refused
none of 15 probes over 30 days
Median open time
1346 ms
Last seen
2026-10-28 06:13:43 UTC
“Answered” is how often our own request got a response, from one region at one probe per day. It is not an uptime figure and must not be read as one. A refusal is a response, so a refused probe counts as answered. "Refused" counts the probes whose answer was 403 or 429.
Transport
TLS
1.3
Certificate expiry
85 days left
Issuer
FNMT-RCM
Chain valid
valid
Name matches
matches
HTTP version
2
Cipher
TLS_AES_128_GCM_SHA256
Address family
v4
Headers and cookies
Header grade
not measured
HSTS
not measured
Mixed content
not measured
Cookie flags
not measured
Redirect hops
1
Exposure check
not measured
The request ended at https://mptmd.gob.es/portal/delegaciones_gobierno/delegaciones. 16 of the 16 probes that got a response ended on a different host, so the fields above may describe that host rather than this one.
Where the time went
DNS (first request) 0 msConnect (first request) 101 msTLS handshake (first request) 0 msRedirects, then waiting for the first byte 2859 msTransfer 34 ms
2994 ms in total, across 2 requests — the first and 1 redirect. Transfer is the remainder after the first byte rather than a separately measured phase.
Only the first request’s DNS, connection and TLS are timed separately, so that segment is not server think-time alone: it carries the other request and anything else between the first connection and the first byte.
The TLS handshake reads 0 ms because the first request was plain HTTP, so there was no handshake to time. The TLS version and certificate above are from the HTTPS hop the origin redirected to, which is a different connection from the one timed here.
527 bytes returned, after 1 redirect.
Registration and published DNS
This top-level domain publishes no RDAP service, so there is no registry record for us to read.
Registry record read over RDAP on 2026-10-25. Neither involves a request to this host, and neither is a test: we read what the registry and the domain’s own DNS publish. A published policy is not evidence about what a mail receiver would actually do.
By observer region
Measured from one region. The per-region comparison §5.5 describes needs more than one, and the deployment has one today.
delegaciondelgobierno.gob.es 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.