Duplicati monitoring broken on Mac OS

Support
1

Hi, I have a backup set up to report to https://www.duplicati-monitoring.com/

When I run if from the UI the back reports that there a 4 warnigns, but there is nothing in the log. When I export the backup to command line and run it there I do get errors.
```
HTTP Response request attempt 1 of 3 failed for: hxxps://www.duplicati-monitoring.com/log/frank%40breedijk[.]net//51672 => The SSL connection could not be established, see inner exception.
HTTP Response request attempt 2 of 3 failed for: hxxps://www.duplicati-monitoring.com/log/frank%40breedijk[.]net//51672 => The request message was already sent. Cannot send the same request message multiple times.
HTTP Response request attempt 3 of 3 failed for: hxxps://www.duplicati-monitoring.com/log/frank%40breedijk[.]net//51672 => The request message was already sent. Cannot send the same request message multiple times.
Failed to send message: System.InvalidOperationException: The request message was already sent. Cannot send the same request message multiple times.
```

The command line is:
/Applications/Duplicati.app/Contents/MacOS/duplicati-cli backup “onedrivev2://Duplicati/laptop/mac_20251222?authid=” /Users/fbreedijk/ --backup-name=Macbook --dbpath=“/Users/fbreedijk/Library/Application Support/Duplicati/DMYIRRXRLQ.sqlite” --backup-id=DB-1 --encryption-module=aes --passphrase=“” --compression-module=zip --dblock-size=50MB --retention-policy=“1W:1D,4W:1W,12M:1M” --send-http-url=“hxxps://www.duplicati-monitoring.com/log/frank%40breedijk[.]net//51672” --disable-module=console-password-input --exclude=/Users/fbreedijk/OneDrive/

It looks like there is a conflict between the encryption of duplicati-monitoring and the ssl environment on Mac. All my other backup Ubuntu and Pi work and report well.

2

The link you gave has advice on contacting the right devs.
This is a third-party product, not from the Duplicati people.

OTOH it’s not totally clear to me which end is causing this.
Possibly the Duplicati dev will have words, or possibly not.

Is that a typo? I would have thought https. Might it help?

3

It is https obviously, not hxxps, but the forum doesn’t allow me to post this with https, because I would the have too many hyperlinks in my post.

Because it is working on ubuntu machines and in a docker container, but not on Mac OS, I suspect the error is on the duplicati site rather than the duplicati-monitoring site.

4

You can avoid the hyperlinking (and prevent double dashes from becoming long
dashes) with backticks around the text. A greater than sign in front will wrap text.

would be something that developers would have to look at. I don’t have a Mac.
You can try both developer sides if you like. I think the Duplicati dev uses Mac.
Actually being able to reproduce a problem to examine it is usually very useful.

When I first Googled the error, people knew of it, but it’s very rare for Duplicati.
Send-http-json-urls produces mysterious warnings saw it, but rather differently.

5

That might indeed be the same issue. The IP of that one is running duplication in a container, so that is different.

I’ve mailed the dev of duplication-monitoring as well.

6

There was also a discussion of sending as attachment vs. body, length limits, etc.
I didn’t re-read too carefully, but I didn’t see suspicions of a TLS issue in that one.
It seemed to be going in a totally different direction, yet it reported the same error.

I see I cited a webhook site then but didn’t spot it, so I just tested webhook.site.
It worked fine with a tiny test backup, 2.2.0.2_beta_2025-11-26, and Windows 10.

You could run a similar test to your choice of webhook test sites, with your setup.
You could even test Duplicati’s own fairly recent console at app.duplicati.com.

My test was also to see how much logging I could have. I run a profiling level log.
What actually logged looked like this, but it might be enough to see retry or error.

2025-12-29 08:33:54 -05 - [Verbose-Duplicati.Library.Modules.Builtin.SendHttpMessage-HttpResponseMessage]: HTTP Response to https://webhook.site/REDACTED: 200 - OK: This URL has no default content configured. <a href="https://webhook.site/#!/edit/REDACTED">Change response in Webhook.site</a>.

I wouldn’t count on the server side setup being the same from place to place, however it’s something you can do if you like, while seeing if dev help arrives.

would be the sort of retry I don’t get but you might, and the code shows configs.
The default --send-http-retries looks like 3, 1 second apart. You posted 3 already in original post, so maybe the test is already done, except for first error.

Finding first error might help, if it can be had in your Verbose level log, then the presumably different failure on retry attempts can be looked at as second issue.

Error handling is sometimes slow to get bug reports if the first error is a rare one.

1 Like