No disable countdown shown

[yubiuser]

Then Pi-hole is disabled for a certain amount of time, the web interface will show a countdown until it gets re-enabled.
However, when Pi-hole is enabled for a certain time, no countdown is shown.

To replicate

$ pihole disable
  [✓] Pi-hole disabled forever
$ pihole enable 5s
  [✓] Pi-hole enabled for 5s                                   <----- No disable countdown shown in Web UI

After 5 sec the web UI will switch back to allow enabling the blocking.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[vbsampath]

Below screenshots confirm the issue, I tried with postman using REST API and it also gives same result.
Basically DNS blocking is not working I guess

Tried to block indefinitely It was blocked In couple of seconds it was enabled

[rdwebdesign]

@yubiuser

The web interface controls for Disable/Enable blocking were created for Pi-hole v5, when there was no possibility to enable Pi-hole just for a few seconds.

At that time, Pi-hole could show 3 states: disabled by a specific time, disabled forever or enabled forever. The countdown only existed on the first 2 items (blocking disabled). Also, the web interface wasn't automatically updated (a page reload was needed to show the new status).

In v6 we improved the web interface to show the status in real time (updated each 10 seconds), but we never created an interface to show when blocking is "temporarily" enabled (this is a forth state). This is a very rare case and maybe not expected to be used.
Currently, the countdown still only exists when blocking is disabled. It needs to be created if we want to show this case.

[rdwebdesign]

@vbsampath

What API requests did you try exactly?

They should look like this (using curl example):

curl -X POST "http://pi.hole/api/dns/blocking" \
 -H 'accept: application/json'\
 -H 'content-type: application/json'\
 -H 'sid: <valid_sid>' \
 -d '{"blocking":true,"timer":30}' 

[yubiuser]

This is a very rare case and maybe not expected to be used.
Currently, the countdown still only exists when blocking is disabled. It needs to be created if we want to show this case.

Yes, it's an edge case. I would assign lowest priority but still something that could be improved.

[vbsampath]

There are no timers involved in my request.

I'm trying to disable pi-hole for a indefinite amount of time by blocking it using API.
I did blocked pi-hole with timer as null which means pi-hole shouldn't be enabled and ads should be allowed right. Since there is no timer it's indefinite right.

Above request says that the pi-hole ad blocking is disabled for indefinite time

The next second I made a get request on the blocking status and I get it as enabled, which it shouldn't be right. It should be disabled indefinitely till I make another request from API/web to enabled pi-hole ad blocking.

I took the response headers timeline to showcase the situation
POST request -> Date: Fri, 21 Nov 2025 14:09:22 GMT
GET request -> Date: Fri, 21 Nov 2025 14:09:26 GMT

I think this as bug. So even when a user makes a request to disable blocking it enables itself after a second or so.
Let's imagine a situation where I need to disable pi-hole for a hour or so, I would disable it but it is not working as expected.

Postman raw logs

POST request

POST /api/dns/blocking HTTP/1.1
Accept: application/json
Content-Type: application/json
sid: 0CHM4nVdkDsV7zYJ7QmrmQ=
User-Agent: PostmanRuntime/7.49.1
Cache-Control: no-cache
Postman-Token: 041364b8-30fa-4f51-8a61-af4d0f0d50cb
Host: pihole.bree
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 47
Cookie: sid=0CHM4nVdkDsV7zYJ7QmrmQ=

{
"blocking": false,
"timer": null
}

HTTP/1.1 200 OK
Server: openresty
Date: Fri, 21 Nov 2025 14:09:22 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 64
Connection: keep-alive
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Expires: 0
Pragma: no-cache
X-DNS-Prefetch-Control: off
Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: sid=0CHM4nVdkDsV7zYJ7QmrmQ=; SameSite=Lax; Path=/; Max-Age=1800; HttpOnly
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
X-Served-By: pihole.bree

{"blocking":"disabled","timer":null,"took":0.041607141494750977}

GET request

GET /api/dns/blocking HTTP/1.1
Accept: application/json
sid: 0CHM4nVdkDsV7zYJ7QmrmQ=
User-Agent: PostmanRuntime/7.49.1
Cache-Control: no-cache
Postman-Token: adcdd148-430d-4c61-a61a-8559ef76f43a
Host: pihole.bree
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: sid=0CHM4nVdkDsV7zYJ7QmrmQ=

HTTP/1.1 200 OK
Server: openresty
Date: Fri, 21 Nov 2025 14:09:26 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 61
Connection: keep-alive
Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
Expires: 0
Pragma: no-cache
X-DNS-Prefetch-Control: off
Content-Security-Policy: default-src 'self' 'unsafe-inline';
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: sid=0CHM4nVdkDsV7zYJ7QmrmQ=; SameSite=Lax; Path=/; Max-Age=1800; HttpOnly
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *
X-Served-By: pihole.bree

{"blocking":"enabled","timer":null,"took":2.288818359375e-05}

[yubiuser]

@vbsampath Please don't hijack issues. You're having a different issue. I moved your issue to a new ticket.