Is your app ready for read-only mode? What Jira Data Center vendors should know
Jira Data Center now has a native read-only mode — and third-party apps aren’t automatically compatible with it. Here’s what that means for you as a developer, and where to go for the details.
Are you a Jira admin rather than an app developer? This post is written for vendors and developers. For a feature overview — what read-only mode does, what it blocks, and how to turn it on — read the companion post: One toggle to freeze your instance: Native Read-Only Mode in Jira Data Center.
Jira Data Center recently gained a native read-only mode. When an admin turns it on — usually for a migration cut-over, an upgrade, or an infrastructure maintenance window — Jira stops write operations so nothing changes while the instance is being worked on. Users can still search, view, and browse, but they can’t create or edit.
If you build apps for Jira Data Center, this is worth a few minutes of your attention, because there’s an important nuance: your app is not automatically compatible.
What this means for your app
Read-only mode is enforced through Jira’s project-permission model. That’s a deliberate design choice, and it has a clean consequence for apps:
-
If your app writes data the “normal” way — going through Jira’s permission checks before it modifies an issue — then it’s already covered. When read-only mode is on, those writes are blocked for you, no extra work required.
-
If your app writes through its own code paths — background jobs, scheduled tasks, event listeners, incoming webhooks, direct manager or SQL calls, or code that impersonates a user — then the read-only gate never sees those writes. They’ll keep happening while the rest of the instance is frozen.
That second case is the one to watch. During a migration or backup, an app that quietly keeps writing is exactly what read-only mode exists to prevent — so if any of your write paths bypass permission checks, they’re your responsibility to guard.
The one subtlety worth flagging
System administrators are exempt from read-only mode, so they can fix issues mid-maintenance without turning it off for everyone. That exemption is meant for a human admin deliberately doing maintenance — not for automated code that happens to run as an admin. It’s an easy trap: reusing a generic “is this an admin?” check can accidentally let your background jobs write during a freeze. Worth keeping in mind when you design your guards.
Where to go next
The good news is that detecting read-only mode is straightforward — there’s a REST endpoint, a server-side property, and an event you can subscribe to — and Atlassian’s developer documentation walks through the exact APIs, the recommended patterns for interactive vs. automated code, and how to test it all.
If you own a Data Center app, it’s worth reviewing your write paths against that guide before your customers’ next migration season.
-
Making your app compatible with read-only mode — the official developer guide, with code and patterns.
-
Using read-only mode for site maintenance — admin-facing documentation for the feature.
-
Understanding read-only mode: what it blocks and what it doesn’t — the operation-by-operation breakdown.
Already added read-only support to your app, or ran into an edge case? Share your experience in the comments.