starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 08:26:00 +02:00

[GH-ISSUE #1391] http 500 error (ntfy error 50001) #981

New issue

Closed

opened 2026-05-07 00:29:19 +02:00 by BreizhHardware · 5 comments

BreizhHardware commented

2026-05-07 00:29:19 +02:00

Owner

Originally created by @TheUser-dev on GitHub (Jul 16, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1391

🐞 Describe the bug
When sending a notification (especially when it happens with multiple requests) this error occurs

💻 Components impacted
ntfy server 2.13.0 in docker, debian 12 arm64

💡 Screenshots and/or logs

closed with HTTP 500 (ntfy error 50001) (error=database table is locked, http_method=POST, http_path=/_matrix/push/v1/notify, tag=http, visitor_auth_limiter_limit=0.016666666666666666, visitor_auth_limiter_tokens=30, visitor_id=ip:<edited>, visitor_ip=<edited>, visitor_messages=448, visitor_messages_limit=17280, visitor_messages_remaining=16832, visitor_request_limiter_limit=0.2, visitor_request_limiter_tokens=57.049697891799994, visitor_seen=2025-07-16T15:06:35.429Z)

🔮 Additional context
Looks like this has already been fixed by #498, regression?

Originally created by @TheUser-dev on GitHub (Jul 16, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1391 :lady_beetle: **Describe the bug** When sending a notification (especially when it happens with multiple requests) this error occurs :computer: **Components impacted** ntfy server 2.13.0 in docker, debian 12 arm64 :bulb: **Screenshots and/or logs** ``` closed with HTTP 500 (ntfy error 50001) (error=database table is locked, http_method=POST, http_path=/_matrix/push/v1/notify, tag=http, visitor_auth_limiter_limit=0.016666666666666666, visitor_auth_limiter_tokens=30, visitor_id=ip:<edited>, visitor_ip=<edited>, visitor_messages=448, visitor_messages_limit=17280, visitor_messages_remaining=16832, visitor_request_limiter_limit=0.2, visitor_request_limiter_tokens=57.049697891799994, visitor_seen=2025-07-16T15:06:35.429Z) ``` :crystal_ball: **Additional context** Looks like this has already been fixed by #498, regression?

BreizhHardware

2026-05-07 00:29:19 +02:00

closed this issue
added the
🪲 bug
label

BreizhHardware commented

2026-05-07 00:29:19 +02:00

Author

Owner

@binwiederhier commented on GitHub (Jul 16, 2025):

ntfy.sh gets almost no 500s, and the volume is much larger. This is a tuning for scale issue. Most notably, check the message cache options.

@binwiederhier commented on GitHub (Jul 16, 2025): ntfy.sh gets almost no 500s, and the volume is much larger. This is a [tuning for scale](https://docs.ntfy.sh/config/#tuning-for-scale) issue. Most notably, check the [message cache](https://docs.ntfy.sh/config/#message-cache_1) options.

BreizhHardware commented

2026-05-07 00:29:20 +02:00

Author

Owner

@TheUser-dev commented on GitHub (Jul 17, 2025):

ntfy.sh gets almost no 500s, and the volume is much larger. This is a tuning for scale issue. Most notably, check the message cache options.

Hello, I applied these settings that were specified in the documentation - now the error does not appear. Thank you!

@TheUser-dev commented on GitHub (Jul 17, 2025): > ntfy.sh gets almost no 500s, and the volume is much larger. This is a [tuning for scale](https://docs.ntfy.sh/config/#tuning-for-scale) issue. Most notably, check the [message cache](https://docs.ntfy.sh/config/#message-cache_1) options. Hello, I applied these settings that were specified in the documentation - now the error does not appear. Thank you!

BreizhHardware commented

2026-05-07 00:29:20 +02:00

Author

Owner

@TheUser-dev commented on GitHub (Jul 17, 2025):

Ah, no, the error still appears even following the documentation
I set the following parameters:
cache-batch-size: 25
cache-batch-timeout: "5s"
cache-startup-queries: |
pragma journal_mode = WAL;
pragma synchronous = normal;
pragma temp_store = memory;
pragma busy_timeout = 30000;
vacuum;

And this is clearly not related to the load, this is the ntfy homeserver that only I use

@TheUser-dev commented on GitHub (Jul 17, 2025): Ah, no, the error still appears even following the documentation I set the following parameters: cache-batch-size: 25 cache-batch-timeout: "5s" cache-startup-queries: | pragma journal_mode = WAL; pragma synchronous = normal; pragma temp_store = memory; pragma busy_timeout = 30000; vacuum; And this is clearly not related to the load, this is the ntfy homeserver that only I use

BreizhHardware commented

2026-05-07 00:29:20 +02:00

Author

Owner

@TheUser-dev commented on GitHub (Jul 18, 2025):

By editing the docker-compose.yml configuration like this, the problem was completely gone! Magic:
version: '3.3'

services:
  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    command:
      - serve
    environment:
      - TZ=UTC
    user: UID:GID
    volumes:
      - /dev/shm/ntfy:/var/cache/ntfy
      - /etc/ntfy:/etc/ntfy
    ports:
      - 8393:8393
    healthcheck: # optional: remember to adapt the host:port to your environment
        test: ["CMD-SHELL", "wget -q --tries=1 http://localhost:8393/v1/health -O - | grep -Eo '\"healthy\"\\s*:\\s*true' || exit 1"]
        interval: 60s
        timeout: 10s
        retries: 3
        start_period: 40s
    restart: unless-stopped

@TheUser-dev commented on GitHub (Jul 18, 2025): By editing the docker-compose.yml configuration like this, the problem was completely gone! Magic: version: '3.3' ```yml services: ntfy: image: binwiederhier/ntfy container_name: ntfy command: - serve environment: - TZ=UTC user: UID:GID volumes: - /dev/shm/ntfy:/var/cache/ntfy - /etc/ntfy:/etc/ntfy ports: - 8393:8393 healthcheck: # optional: remember to adapt the host:port to your environment test: ["CMD-SHELL", "wget -q --tries=1 http://localhost:8393/v1/health -O - | grep -Eo '\"healthy\"\\s*:\\s*true' || exit 1"] interval: 60s timeout: 10s retries: 3 start_period: 40s restart: unless-stopped ```

BreizhHardware commented

2026-05-07 00:29:20 +02:00

Author

Owner

@TheUser-dev commented on GitHub (Jul 18, 2025):

Although no. The problem is still relevant
The problem appears ONLY in Docker
When using the program natively, the problem disappears
It's very strange and to be honest it really confuses me.

@TheUser-dev commented on GitHub (Jul 18, 2025): Although no. The problem is still relevant The problem appears ONLY in Docker When using the program natively, the problem disappears It's very strange and to be honest it really confuses me.