Hey, Jira Guys and Gals. Yes, it’s been a minute. I needed a (few) Mental Health Month(s). That said, I was hardly idle – what with The Jira Life Podcast, JiraCon, Jira Day, welcoming a new cohort of Atlassian Creators, and more – I stayed busy. 

The intermediate business leads me to today’s post. I got a question a few weeks ago that caught my attention. When I first read it, I immediately responded, “Really, how do you answer that?” There are so many variables that went into their simple question that I initially struggled to answer it. I even had to check with the Atlassian Abyss to make sure I got all the details.  

And what could have me so flummoxed? Well, you see, this consultant has a customer who wants to restart their Jira Server instance every week within a maintenance window. What they wanted to know was if I had any experience or documentation about what time would be best to do the restart. That is a deceptively simple question with some deep implications once you consider it – especially considering, as I confirmed later, the customer was on Jira Server.

I’ve already put out a quick LinkedIn Carasoul about this subject last week, which I’ll put here, but let’s take a second to dig into this and see what you should consider when looking at this simple question. 

What’s in a restart?

So first: nomencleture. When we say restart, we usually mean restarting the Jira service on a Server. If you are on Jira Cloud, this is not something you have to worry about, as this is a SysAdmin function Atlassian handles.  

There are several reasons why you might want to consider restarting the service. Doing so lets your JVM pick up new or adjusted parameters and can often be a relatively innocuous debugging step. Especially on D.C., where you can restart in a way that doesn’t cause downtime, that’s usually the first question that teammates ask when responding to an incident with Jira. 

That being said, unless you need to adjust some settings or see problems, there generally is no need for Jira to be restarted regularly. No, seriously, at one point, I even went an entire year without bringing the Jira service down. Now, I don’t recommend going to that extreme either – especially in today’s age of relatively rapid Jira releases and recurring security concerns, leaving your Jira service running that long also seems irresponsible. 

So, an annual restart is irresponsible, but a weekly restart is also excessive. That being said, the only damage restarting too often is a really, REALLY slim chance you can damage your system index, but that is solved by – you guessed it – a reindex. So, if you have a customer who insists on restarting weekly, it won’t hurt much, so go for it. 

There are different kinds of Restarts.

So – depending on whether you use Jira Server or Data Center, there are different restarts for you to consider.

To clarify, you only have an option if you are on Data Center. If you are on Jira Server, restarting your Jira service leaves nothing to serve client requests, meaning your Jira instance is down. A typical server restart takes about five or so minutes, so the downtime isn’t terrible, but I still feel the need to babysit logs every time I do a restart.  

However, if you are on Data Center, you have options. You see, rather than restarting all the nodes at once, you can perform a “Rolling Restart,” where you restart each node one at a time and then wait for it to come back up before moving to the next node. This methodology leaves the other nodes to serve incoming requests, meaning while degraded, Jira is not down.

This method has a relatively low impact on the users. If a user is on the node currently restarting (and assuming your load balancing is set up correctly), they will be shuffled onto one of the other active nodes while that node is down. What this looks like to them is Jira suddenly asks for them to log in again – and if you are using SSO, not even that. 

The alternative on Data Center is more extreme but required on rare occasions. This is where you bring all the nodes down at the same time and then bring them back up. This methodology is generally only required to clear the user cache or similar and is not something you should plan to do often on Data Center. Jira DC will often want to run a reindex before coming up fully in this situation, so you might be waiting a bit longer than normal.  

When should you do a restart?

So, now that we have the background done, it’s meat and potatoes time. Atlassian does not provide docs for this question. That is because there are many factors to consider, and how important each factor is will vary from organization to organization. Among the questions I normally ask are:

• Where are my users located in the world? How many different timezones are they located in, and what timezones are they?
• Are there any mission-critical workflows on my Jira instance, and can they tolerate downtime?
• Is there a regular maintenance window, and if so, can I wait for it?
• How many people will be affected by an outage, and is that acceptable?
• Is it more likely for me to have an unplanned outage or degraded system if I don’t take a planned outage?
• Are there any events where you can expect higher-than-average Jira usage coming up?
• Are there any change management processes or approvals required? How much lead time do they need?

Ideally, you want to target any potential outage of your Jira service when the fewest people are using your system. What that means will be different for each org. As a few examples:

 Is your entire company within the U.S.? Any day after 6 p.m. Pacific should work.  

Do you have offices in Sydney, Beijing, New Delhi, Tel Aviv, Paris, Boston, Austin, Palo Alto, and Honolulu? I hope you are okay with working Saturdays then because with that spread, you aren’t getting a clear time zone to work with otherwise. 

Then, you need to consider the impacts your system being down could cause. Even with a Rolling restart, you still need to treat it as a downtime event in case something goes wrong and you need to do a full restart. Does your company rely on this Jira instance to manage other I.T. Incidents and Change Requests? What is your plan for if the system of record is also the system undergoing a change request?  

Especially for software companies (where I have most of my experience), Software release times are especially sensitive to downtimes – so much so that I won’t even plan an upgrade around a product release, let alone a restart.  

See what I mean? It’s a simple question that has a lot of factors. But so long as you understand your user base and their habits, it’s not an impossible question to answer.

Again, Communication is key.

So, you’ve gone through and, based on the factors that are important to your organization, you’ve picked a time to do your restart. You should be good to go, right? 

Well, here’s the thing. Do you know the last thing you need when doing a restart? A hundred emails asking if Jira is down. That is why you need to notify users early and let them know Jira can potentially be down. Even if you are doing a rolling restart, there is always a chance you will end up doing a full restart.  

Now, I’m no fool (most of the time). Even if you put out a notification, there will be someone who doesn’t read the email and will still email you if Jira is down. But the difference is one email vs hundreds, so it’s worth it. 

I’m Back, baby!

So what do you think? Is there anything you consider for a restart that I haven’t covered? Let me know!

I’ve got a good few plans, and I’m even working on how I can still monetize the blog without it being obnoxious. I’ve heard you – you don’t care for App Reviews. The numbers just don’t lie. I have one last App review in the pipeline – fair warning, but after that, the options I’ve come up with are much better, I think.  

Don’t forget to tune into The Jira Life tomorrow at 5 PM, where myself and Alex are going over Atlassian’s new announcements this week as well as a new critical security alert on Confluence.  

But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”