I would like to get feedback on optional notifications for long-running or unattended rclone copy operations.
I have prepared an initial implementation that sends Telegram notifications when a copy starts, updates the same message with progress, and reports the final result.
Notifications are enabled explicitly using a saved profile:
The initial proposal covers only copy and Telegram. Notification failures are logged without changing the copy operation’s result or exit status.
GitHub issue, including screenshots:
Implementation, tests and documentation:
I would like the notification mechanism to be easy to extend. If the approach is accepted for inclusion in rclone, I am willing to implement and test support for sync and move, as well as additional providers such as Slack or Discord.
Would this be useful for your workflows? I would appreciate feedback on the configuration approach, notification behaviour, and which commands or providers would be most useful.
opt-in notify profile is the right shape for me. keep it off the exit code like u said.
id want:
-same flag working on sync / move later, not only copy
-rate limit so a 10k file run doesnt spam telegram (edit-in-place like u sketched is fine)
-a dry way to test the bot token without starting a real copy
- I’d like to support the same `--notify PROFILE` flag on `sync` and `move` once the overall approach is agreed with the maintainers.
- The current implementation already edits one message per profile. Progress updates use a configurable interval, currently 5 seconds by default, rather than being triggered for each file. If delivery is slow, newer progress replaces the pending update instead of building up a queue.
- A dedicated way to test a notification profile without starting a file operation makes sense. That isn’t implemented yet, but I’m happy to add it. An explicit “send test notification” action could check both the credentials and delivery to the configured chat.
IMO more configurable options you provide it will be better. People have very different requirements and opinions:) Well designed and implemented tool should provide enough flexibility to make majority happy.
At least this is my opinion. How you proceed is entirely up to you.
I agree that users have different requirements and that the notification system should remain extensible.
However, for the first iteration, I would prefer to implement a common framework for independent providers and start with a built-in Telegram provider. Email, Slack, and other delivery methods could then be added without changing the overall approach.
Users would select the profiles they need and could combine them in a single run. For example, once email support is added, this could look like:
For popular services, built-in providers seem simpler for users: they would only need to configure a profile, without writing and maintaining their own scripts. Shared retry logic and delivery timeouts could be handled by the notification system, while API-specific behavior and message formatting would be left to individual providers.
I’m not ruling out support for user-defined scripts: it could be considered in a later iteration, as another provider for custom integrations. This would allow built-in delivery methods and scripts to coexist and be selected through the same profile mechanism.
Thanks for the discussion! I’d like to clarify the maintainers’ position: would a built-in notification mechanism with profiles selected via --notify PROFILE be suitable in principle for inclusion in rclone?
For the initial PR, I propose supporting only copy and Telegram, with an extensible design that allows other commands and delivery methods, including custom scripts, to be added later. Would you be open to reviewing a PR along these lines, or would you prefer changes to the proposed design or scope first?
I'm not really interested in a specific feature for just copy and telegram.
The idea of hooks into rclone has been proposed before and a general purpose hook mechanism would be useful
We'd need a general purpose mechanism for hooks and the hooks should be a local command which is invoked.
This keeps it completely agnostic.
Take a look at
--password-command SpaceSepList Command for supplying password for encrypted configuration
and
--metadata-mapper SpaceSepList Program to run to transforming metadata before upload
For previous implementation of hook like things.
So we could make something like
--event-notify SpaceSepList Program to run to deal with an event in rclone.
To do this properly is a lot of work. There are maybe 30 or so events rclone could generate.
I think your particular use case would be satisfied with a little script to read the exit code of rclone and maybe tail the log (you can use --use-json-log to make it easy to parse).
I'm going to close your current issue as it is not general purpose enough and has too much business logic (how to talk to telegram) in the rclone code.
Thank you for explaining your reasoning. I understand and respect the preference for a general-purpose hook mechanism. Where I think we differ is on the experience we want to offer ordinary users.
I chose rclone because it is straightforward to use and already supports the storage providers I need. I can configure those integrations without having to build and maintain them myself. I would like notifications to offer a similar experience: configure a supported provider, such as Telegram or Slack, and enable it.
I like the flexibility of custom hooks. My concern is that making an external script or helper a requirement adds another component users must find, configure, update, and troubleshoot. Even when ready-made handlers are available, that is more work than configuring a built-in integration. Maintaining separate scripts for common needs also means duplicating effort across users.
For context, I have already been using a wrapper around rclone for almost a year to read its logs and send notifications to Telegram. So I understand that this is possible externally. My proposal came from wanting to make that experience simpler and accessible to users who would not maintain such a setup themselves.
I understand the maintenance cost of adding notification providers to rclone. However, I am concerned that notifications will remain a niche feature if using them requires assembling an external solution.