Background jobs - inconsistent /delay - Email notification Behaviour?

Hi, a ‘fun’ question. I’ve been testing (Nextcloud 12.0.2 on Ubuntu 16.04 LTS latest patched) and I’ve adjusted config so there is a scheduled cron job / as per the docs recommended example / that runs hourly / to trigger notifications to be sent that are pending.

What I’m noticing is that,

  • generally the delay between file activity, and notification uploads - is somewhat out of sync - and generally I wait longer than an hour for a notification email to be sent.

For example,

  • File is uploaded at 749pm to a folder owned by User1
  • User1 has notification-via-email enabled for file-change-upload / on ‘hourly’ basis batching in user-prefs / which appears to be the ‘most frequent’ setting I am permitted.
  • cron job runs every 15minutes / as a www-data crontab entry / as per the docs suggestion ( )
  • and what I see is that the email notification does get sent, but not until 900pm, ie, not 800pm.

So possibly the ‘first hour delay trigger’ gets the email queued; and then the cron job is only then allowed to pick up the notification after that?

I’m curious if anyone has noted this behaviour (ie, not just me) / if there is any workaround (ie, put cron job slightly later or earlier? or run slightly more often?)

I do note this discussion / located via google searching,

which suggests there is a way to customize code to make the ‘hourly’ notify actually be less-than-hourly (ie, 15minutes, 10minutes, - just by hard-code-dropping the ‘seconds’ linked to the item.) But ideally I prefer to avoid making customization / kludge to the app source code, since this is something I have to keep re-doing each time I update the software…

Anyhow. Curious if there is a good/easy/known fix / change request maybe in the pipeline for notification frequency of <1 hour / which might actually work on that sort of basis.

I’m not looking for ‘immediate’ notifications, but if for example I could get ‘reliable’ notification on 15 or 30minute latency, that would be nice. This is not a high-volume server (small office, 5 staff) so I’m not worried about ‘too much workload’