[Question] Multiple Telegram notifications for a single scheduled speedtest when using Apprise + thresholds (non-intuitive behavior)

[aferende]

Pre-work

• I have read the docs.
• I have searched open and closed issues.
• I agree to follow this project's Code of Conduct.

Description

When using Speedtest Tracker with Apprise notifications (Telegram) and thresholds enabled, a single scheduled speedtest can generate multiple identical Telegram messages (2 or sometimes 3), all referring to the same test result.

This behavior is confusing and non-intuitive, especially because thresholds appear to be treated as separate notification triggers, rather than as conditions on a single test result.

The duplication occurs only for scheduled speedtests, not for manual tests or direct Apprise test notifications.

Expected Behavior

• A single speedtest (scheduled or manual) should generate one notification
• If thresholds are violated, this should be:
  • clearly indicated within the same message, or
  • optionally handled by a distinct and explicitly configured alert channel
• Threshold evaluation should behave as result metadata, not as an implicit additional notification trigger

Steps to Reproduce

1. Deploy Speedtest Tracker
2. Configure Apprise as the notification provider
3. Configure Apprise to send notifications to Telegram
4. Enable thresholds (download / upload / ping)
5. Enable the following notification options:
   • Notify on every scheduled speedtest run
   • Notify on threshold failures for scheduled speedtests
6. Wait for a scheduled speedtest to run

A single scheduled speedtest produces multiple identical Telegram notifications.

Deployment Environment

Docker Run

Application Information

- Speedtest Tracker running in a Docker container
- Scheduled speedtests enabled (daily)
- Thresholds enabled
- Notifications routed exclusively through **Apprise**
- No legacy Telegram notification channel enabled

What browser(s) are you seeing the problem on?

Chrome (latest)

Logs

No errors are shown in application logs.

Apprise and Telegram behave correctly and forward exactly what they receive.  
The duplication appears to originate from **multiple notification triggers being fired for a single scheduled speedtest**, rather than from retries or transport errors.

If needed, I can provide sanitized logs or enable debug logging for further investigation.

[svenvg93]

In the container logs do you also see to log entries for both the notifications, there should be an info log.

[aferende]

Thanks for the suggestion — I’ve checked both Speedtest Tracker and Apprise container logs, and this is what I’m seeing.

---

Apprise logs

Apprise is working correctly.

When it receives a notification request, it logs it clearly and sends the Telegram message as expected, for example:

[INFO] apprise: Sent Telegram notification.
[INFO] django: NOTIFY - Delivered Notification(s)
POST /notify/... 200

This confirms that:

• Apprise is reachable
• Apprise is not duplicating messages
• Telegram delivery works as expected

However, during the scheduled speedtest at 07:00, there is no POST request to /notify at all.

That means Apprise is never called, so it cannot send any notification.

---

Speedtest Tracker logs

The scheduler itself is running correctly. The following entries are present around the scheduled time:

artisan schedule:run -q
crond: USER abc cmd /usr/bin/php /app/www/artisan schedule:run -q

The speedtest result is correctly stored and visible in the Results UI, so the test is definitely executed.

However, there are no log entries related to notifications, such as:

• notification dispatch
• apprise
• notify
• sending notification

This indicates that Speedtest Tracker does not emit a notification event for that scheduled test.

---

Important observation

The behavior changes depending on the notification flags:

When BOTH options are enabled:

• ✅ Notify on every scheduled speedtest run
• ✅ Notify on threshold failures for scheduled speedtests

Result:

• Notifications are sent
• In some cases, multiple identical notifications are sent for a single scheduled test

---

When ONLY this option is enabled:

• ✅ Notify on every scheduled speedtest run
• ❌ Notify on threshold failures for scheduled speedtests

Result:

• The scheduled speedtest runs and is stored
• No notification is sent at all

This happens even though:

• the test completes successfully
• thresholds are still configured
• the “notify on every scheduled speedtest run” option is enabled

---

Conclusion

From logs and behavior, it appears that:

• The threshold failure notification is effectively acting as the only notification trigger for scheduled tests in some cases
• Disabling it can result in no notification being emitted at all
• Enabling it can result in duplicate notifications

So the system currently oscillates between:

• over-notifying (duplicates)
• under-notifying (no notification)

depending on the flag combination.

Apprise and Telegram are not the cause — they simply forward what they receive.

---

Open questions

• Is this behavior expected or intended?
• Should “Notify on every scheduled speedtest run” be sufficient on its own?
• Would it make sense to decouple:
  • result evaluation (thresholds)
  • notification emission (single event per test)

Happy to provide additional logs or help test a fix if needed.

[aferende]

Follow-up Analysis: Duplicate Notifications with Thresholds Enabled

This is an update to my previous report. After re-enabling "Notify on threshold failures for scheduled speedtests", the issue is reproducible again.

On the morning of 2026-01-02, a single scheduled speedtest generated three identical Telegram notifications.

speedtesttracker_logs.txt
apprise_logs.txt

Below is a detailed analysis based on container logs.

---

Summary of Observed Behavior

• A single scheduled speedtest is executed once and stored correctly.
• With threshold notifications enabled:
  • 3 identical Telegram notifications are delivered.
• With threshold notifications disabled:
  • 0 notifications are delivered.
• Apprise receives multiple POST /notify calls for the same speedtest.

This confirms that the duplication originates upstream, before Apprise.

---

Speedtest Tracker Logs (Scheduler)

Speedtest Tracker runs the scheduler repeatedly (once per minute), but the speedtest itself is executed once:

2026-01-02T08:00:00Z crond: USER abc cmd /usr/bin/php /app/www/artisan schedule:run -q

Subsequent log lines show only repeated scheduler wakeups, not new speedtest executions.

There is no evidence of multiple speedtests, only repeated scheduler runs.

---

Apprise Logs (Key Evidence)

Apprise clearly shows multiple notification attempts within the same minute window:

2026-01-02 00:00:56 [INFO] apprise: Sent Telegram notification.
2026-01-02 00:00:58 [INFO] apprise: Sent Telegram notification.
2026-01-02 00:00:58 [INFO] apprise: Sent Telegram notification.

These correspond to three separate POST /notify requests coming from Speedtest Tracker.

Additionally, failed and retried requests are visible:

POST /notify HTTP/1.1 499
epoll_wait() reported that client prematurely closed connection

This strongly suggests multiple notification dispatch attempts for the same result, not retries caused by Apprise.

---

Root Cause Analysis

Based on the evidence:

1. The speedtest itself runs once
2. Multiple notification dispatches are triggered for the same result
3. The triggers confirmed are:
   • scheduled test completion
   • threshold evaluation
   • stateless threshold notification

These appear to be independent notification paths, all firing for the same scheduled test.

In particular:

• Enabling threshold notifications activates additional stateless notification dispatches
• These are not deduplicated against the main scheduled notification

This results in:

• 1 notification for scheduled run
• 1+ notifications for threshold evaluation
• possible retries due to short-lived HTTP connections

---

Why This Is Not an Apprise Issue

• Apprise sends exactly one Telegram message per POST request
• Logs show no internal duplication
• Apprise does not retry successful sends

Apprise simply forwards what Speedtest Tracker sends.

---

Expected / Desired Behavior

• A scheduled speedtest should emit one logical notification event
• Threshold violations should:
  • annotate that event, or
  • trigger a single additional alert (configurable)
• Multiple dispatch paths should be deduplicated per result ID

---

Suggested Improvements

• Introduce a single notification pipeline per speedtest result
• Deduplicate notifications by result ID
• Clearly separate:
  • scheduled notifications
  • threshold alerts
• Optionally allow:
  • one combined message
  • or distinct channels per event type

---

Conclusion

The current behavior makes it impossible to configure:

• exactly one notification per scheduled test
• without either:
  • duplicate messages, or
  • no messages at all

I’m happy to help test a fix or provide additional logs if needed.

[svenvg93]

Thanks for the extensive information. it's normal that the scheduler runs every minute. This is to check if there a test to run. Notifications are handled by the worker.

I did some testing as well and I can't see the same behaviour.
(I tested with Discord as I don't use telegram, but that does not matter for apprise)

Note time is an hour difference due to UTC vs Local time

Test 27 - Only `Notify on every scheduled speedtest run` enabled

Log: 
[2026-01-02 08:47:14] local.INFO: Apprise notification sent {"channel":"discord://145190111xxxxx/UfB1kIJ4cC9D2y68xkzMBcaY4zkGPkv2WcEFs9vw36q9kSa3xxxx-dOIbwlkqYYx","instance":"http://speedtest-tracker-apprise-1:8000/notify"} 

Test 28 - Both `Notify on every scheduled speedtest run` and `Notify on threshold failures for scheduled speed tests` enabled.

No thresholds were breached , only the completed notification as expected.

Log: 
[2026-01-02 08:48:14] local.INFO: Apprise notification sent {"channel":"discord://14519011108xxxxxx/UfB1kIJ4cC9D2y68xkzMBcaY4zkGPkv2WcEFs9vw36xxxxxxxxdOIbwlkqYYx","instance":"http://speedtest-tracker-apprise-1:8000/notify"} 

Test 29 - Both `Notify on every scheduled speedtest run` and `Notify on threshold failures for scheduled speed tests` enabled.

Thresholds were breached , only the thresholds notification as expected.

Log:
[2026-01-02 08:49:14] local.INFO: Apprise notification sent {"channel":"discord://1451901110xxxxxxx/UfB1kIJ4cC9D2y68xkzMBcaY4zkGPkv2WcEFs9vw36q9kSxxxxxxxx","instance":"http://speedtest-tracker-apprise-1:8000/notify"} 

This indicates that the logic is doing what it need to do

---

From the Apprise logs for the test executed at 07:00, it appears that the session is being closed after 5 seconds with an HTTP 499 status code. This happens because Apprise does not send a response within the configured 5-second timeout.

As shown in the logs below, Apprise takes more than 5 seconds before it actually sends the Telegram notification:

2026-01-02T06:00:46.944873171Z 172.17.0.1 - - [02/Jan/2026:06:00:46 +0000] "POST /notify HTTP/1.1" 499 0 "-" "GuzzleHttp/7"
2026-01-02T06:00:52.518706216Z 2026/01/02 06:00:52 [info] 36#36: *21 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 172.17.0.1, server: , request: "POST /notify HTTP/1.1", upstream: "http://unix:/tmp/apprise/gunicorn.sock:/notify", host: "192.168.100.105:8888"
2026-01-02T06:00:52.519274360Z 172.17.0.1 - - [02/Jan/2026:06:00:52 +0000] "POST /notify HTTP/1.1" 499 0 "-" "GuzzleHttp/7"
2026-01-02T06:00:56.993672092Z 2026-01-02 00:00:56,953 [INFO] apprise: Sent Telegram notification.
2026-01-02T06:00:56.994202416Z 2026-01-02 00:00:56,957 [INFO] django: NOTIFY -  - Delivered Stateless Notification(s)
2026-01-02T06:00:58.296626736Z 2026-01-02 00:00:58,259 [INFO] apprise: Sent Telegram notification.

Interestingly, logs from an earlier notification show that Apprise handled the request much faster and returned a clean HTTP 200 OK:

2026-01-01T09:42:01.706428052Z 172.17.0.1 - - [01/Jan/2026:09:42:01 +0000] "POST /notify HTTP/1.1" 200 96 "-" "GuzzleHttp/7"
2026-01-01T09:42:01.700857226Z 2026-01-01 03:42:01,700 [INFO] apprise: Sent Telegram notification.
2026-01-01T09:42:01.705259492Z 2026-01-01 03:42:01,704 [INFO] django: NOTIFY -  - Delivered Stateless Notification(s)
2026-01-01T09:42:01.776343422Z 2026/01/01 09:42:01 [info] 36#36: *10 client 172.17.0.1 closed keepalive connection

At this point, the only explanation I can think of is that Apprise occasionally needs more time to process the notification, exceeding our configured timeout. Since many other users successfully use Apprise with Telegram, I don’t believe this is an application-side issue.

--

We also do not implement retries when sending notifications. This makes it particularly interesting that three POST requests appear in the logs. Is there possibly a proxy or another component sitting between Speedtest Tracker and Apprise?

Additionally, could you please share the output of: docker logs speedtest-tracker

There should be an entry similar to the following after a speedtest run:

[2026-01-01 14:54:28] production.INFO: Apprise notification sent {"channel":"discord://1451901110825xxxx/UfB1kIJ4cC9D2y68xkzMBcaY4zkGPkv2WcEFs9vw36q9kSxxxxx-dOIbwlkqYYx","instance":"http://apprise.xxxxxx.com/notify"} 

Lastly, please also share your Docker Compose configuration for Speedtest Tracker.

[aferende]

Follow-up: logs, setup details and timeout hypothesis

Thanks for the detailed feedback. Below I’m answering your questions and adding the requested information.

---

Container topology

• Speedtest Tracker and Apprise are running as two separate containers in Synology Container Manager.
• They are on the same Docker bridge network.
• There is no reverse proxy, load balancer, or other component between them.
• Speedtest Tracker calls Apprise directly over HTTP (POST /notify).

---

Speedtest Tracker container startup

Speedtest Tracker is started with a plain docker run (no custom HTTP settings):

docker run -d --name=speedtest \
  -p 8999:80 \
  -p 8443:443 \
  -p 8995:9000 \
  -e PUID=1026 \
  -e PGID=100 \
  -e TZ=Europe/Rome \
  -e DB_CONNECTION=sqlite \
  -e DB_DATABASE=/config/database.sqlite \
  -e TELEGRAM_BOT_TOKEN=redacted \
  -v /volume1/docker/speedtest:/config \
  --restart always \
  ghcr.io/alexjustesen/speedtest-tracker:latest

According to the official documentation:
https://docs.speedtest-tracker.dev/getting-started/environment-variables

there currently does not appear to be any environment variable to control HTTP / Apprise / Guzzle timeouts.

---

Relevant Speedtest Tracker logs

As expected, the scheduler runs every minute. Around the scheduled test time (07:00 local):

crond[277]: USER abc pid 7173 cmd /usr/bin/php /app/www/artisan schedule:run -q
crond[277]: USER abc pid 7176 cmd /usr/bin/php /app/www/artisan schedule:run -q
crond[277]: USER abc pid 7179 cmd /usr/bin/php /app/www/artisan schedule:run -q

What I do not see in the Speedtest Tracker logs after the scheduled run is an entry like:

Apprise notification sent

which suggests Speedtest Tracker never receives a successful HTTP response from Apprise.

---

Relevant Apprise logs (Telegram)

For the same scheduled run, Apprise logs show the following sequence:

2026-01-02T06:00:46Z "POST /notify HTTP/1.1" 499 0 "-" "GuzzleHttp/7"
2026-01-02T06:00:52Z "POST /notify HTTP/1.1" 499 0 "-" "GuzzleHttp/7"
2026-01-02T06:00:56Z [INFO] apprise: Sent Telegram notification.
2026-01-02T06:00:58Z [INFO] apprise: Sent Telegram notification.
2026-01-02T06:00:58Z [INFO] apprise: Sent Telegram notification.

Interpretation:

• Speedtest Tracker closes the HTTP connection after ~5 seconds (HTTP 499).
• Apprise continues processing and eventually sends the Telegram message.
• Because Speedtest Tracker never receives a 200 OK, it never logs a successful notification.
• Other notification paths (scheduled / threshold / stateless) then fire, resulting in multiple POSTs and duplicate Telegram messages.

For comparison, earlier notifications that completed faster show the expected behavior:

"POST /notify HTTP/1.1" 200 96 "-" "GuzzleHttp/7"
[INFO] apprise: Sent Telegram notification.

---

Hypothesis

Based on the above, the behavior looks consistent with a timeout issue:

• Telegram via Apprise sometimes takes longer than the default HTTP timeout.
• Speedtest Tracker treats the request as failed once the timeout is reached.
• There is no retry logic, but multiple notification paths still execute.
• Since the timeout does not appear to be configurable via env vars, it’s not clear how to mitigate this from the user side.

This would also explain why the issue:

• is reproducible with Telegram
• is not reproducible with Discord
• only happens intermittently

---

Open question

Is there currently any supported way in Speedtest Tracker to:

• increase the HTTP timeout when calling Apprise, or
• treat a timeout differently (e.g. log attempt, deduplicate by result ID)?

If not, this might be an area for a small enhancement, as the current behavior can lead to duplicate notifications even though Apprise eventually succeeds.

Thanks again for looking into this.

[svenvg93]

Note

please don't put all the responses through AI. It is making assumptions about how the application works that are wrong. It's only confusing. Thanks!

Relevant Speedtest Tracker logs

As expected, the scheduler runs every minute. Around the scheduled test time (07:00 local):

crond[277]: USER abc pid 7173 cmd /usr/bin/php /app/www/artisan schedule:run -q
crond[277]: USER abc pid 7176 cmd /usr/bin/php /app/www/artisan schedule:run -q
crond[277]: USER abc pid 7179 cmd /usr/bin/php /app/www/artisan schedule:run -q

Are you sure you're looking at the correct logs? There should be far more in there and nothing in relating to the scheduler.
Please run docker logs speedtest-tracker and provide only those logs.

• Because Speedtest Tracker never receives a 200 OK, it never logs a successful notification.
  True, but we do log when it fails after 5 seconds:

[2026-01-02 13:55:20] local.ERROR: Apprise notification failed {"channel":"discord://1451901110xxxxx/UfB1kIJ4cC9D2y68xkzMBcaY4zkGPkv2WcEFs9vw36q9kSa30xxxxxxxxx","instance":"http://192.168.1.5:8000/notify","message":"cURL error 28: Operation timed out after 5002 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for http://192.168.1.5:8000/notify","exception":"Illuminate\\Http\\Client\\ConnectionException"}

• Other notification paths (scheduled / threshold / stateless) then fire, resulting in multiple POSTs and duplicate Telegram messages.

No, There is only one path for notifications. As I proofed above only the needed notification is sent.

This would also explain why the issue:

• is reproducible with Telegram
• is not reproducible with Discord
• only happens intermittently
  .

I Don't believe it is related to Telegram, as mentioned before there are other users using Apprise with Telegram without a problem. Neither is the Speedtest tracker "aware" which service you sent it to. We just grab the URL you set and give it as a parameter to Apprise.

I will check if we want to increase the timeout, it feels more like a workaround and solution to the problem, which is the slow response from Apprise.

[aferende]

Hi, I apologize for the comments. I only used IA to format the message, but it seems I missed a few comments.

The log file with timestamp is attached.

speedtest-tracker.log

Here some screenshots:

Thanks again for your support.

[svenvg93]

No worries, it just became a bit hard to distinguish between the information you provided and what the AI interpreted as the problem 😉

I’ve figured out why you’re seeing three POST requests on failure, even though we don’t explicitly retry in the code. The image is built by LSIO, and they’ve configured the queue worker to retry failed jobs three times. That explains the three POST messages we’re seeing.

I’ll look into whether we can handle this better on our side.

Just to be clear, as mentioned before, these are workarounds to compensate for a slow Apprise instance. The real fix should be addressing why the Apprise instance itself is sometimes so slow.

[aferende]

Great, thank you.
I've been experiencing quite high latency these past few weeks because I'm moving dozens of TB of data on my NAS from one LUN to another, which definitely affects the timeout.
It would be great, if possible, to have an environment variable on SpeedTest Tracker that I can set for cases like this.
Thanks again for the support.

[svenvg93]

Great, thank you. I've been experiencing quite high latency these past few weeks because I'm moving dozens of TB of data on my NAS from one LUN to another, which definitely affects the timeout. It would be great, if possible, to have an environment variable on SpeedTest Tracker that I can set for cases like this. Thanks again for the support.

I had a quick chat with Alex about the timeout, we will increase the default to 30 seconds in the next release.

[aferende]

Ty guys!