DC read-only mode: Scheduled Jobs and sending E-Mails

Hi Folks,

we have a Scheduled Job that is able to send out e-mails. We asked ourselves whether this should be considered a violation of Confluence’s read-only mode, as sending out e-mails could theoretically be considered writing data.

If in fact we should not send out e-mails during read-only mode, how should one handle jobs that perform write operations? Would it be reasonable to simply stall the job until read-only mode is disabled (e.g. sleep 60 seconds, check, repeat)? What do you guys do in your jobs to preserve read-only mode compatability? :slight_smile:


When asking a similar question, I got the following guideline from Atlassian:

“Ideally it should not be possible for users to change anything which could be lost following the maintenance activity (e.g. in the case of an upgrade and being redirected to a fresh database).”

Since sending emails does not make changes to the database or system configuration that could be lost, I would say it’s totally acceptable to do it during read-only mode.

1 Like

Thanks for your reply @metin! :slight_smile:

I just noticed that in this article for implementing read-only modes in apps it says:

Read-Only Mode for Data Center customers helps admins perform routine maintenance, recover from unexpected problems, or prepare to migrate content to a new site. When a site is placed in read-only mode, users will be able to view pages and their history, but not create, edit, comment, copy or move content. Administration actions such as changing site configuration are not restricted.

The last sentence is particularly interesting because we’ve been rigorously preventing all write operations for our apps in read-only mode. This also means configuration stuff which I guess should actually be allowed according to this article?

From my personal point of view I’ve always seen read-only mode kind of like a “secure boot mode” of an OS. So as an admin I would like apps to do as little as possible during it. I thought it to be good practice to lock down your apps as much as possible during read-only mode. But If I understand correctly it should even be allowed to configure apps in read-only mode, so maybe I’ve misinterpreted it a little and we can take a much leaner approach in the future.

I’d like to wait for an Atlassian to give an offical response to this (maybe @bmagro has something to say?) but otherwise if nothing happens I’ll probably just go ahead an mark you answer as a solution. :slight_smile:

To be honest, I had presupposed that you already know the article you have linked to now. I think it wraps up the necessary basics.

Administrative configurations should be possible, assuming that admins know what they do – and when. However, I was even told that is acceptable if user profile settings can still be made. I believe this should be avoided, if possible. Probably, the basic guide lines should be:

  • Do not allow contents to be changed (it could be lost)
  • Allow administrative configuration changes, so not to restrict administrators in their work
  • Better not allow users to change their profile settings unless there is a reason for it and it’s easy for them to redo it

Well, I probably have read that article many times last year but of course I don’t remember every single word and sentence in it. :wink:

Thanks for the additional Info! :slight_smile:

1 Like

I wasn’t involved of the original implementation of read only mode, but the accepted answer sounds reasonable to me.

CC @rbattaglin

1 Like