Management is still terrible

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Management is still terrible

L0 Member

We've been using this platform for over a year now and the interface is not great to say the least. It takes no less than 30 minutes to make the most basic change. Is anyone else feeling the pain? Our SE is useless. Please create a Java client to remove the burden from the appliance.


L4 Transporter

Totally agree, the most complaints we receive during eval from clients is the slowness of the WebUI.

Also compared to other FW vendors this is the slowest user interface I have seen so far.

Not applicable


got to agree, each interation of s/w update has made the front end slower and slower. Shame as its the only downside to a great product. Think they should spend time on tweaking the front end in future releases.


L4 Transporter

Hello Everyone,

I have been working on Palo from version 3.1 all the way to 4.1.3.  Honestly speaking, there has been a considerable change in version 4.1.x.  Can I ask which version are you running at the moment.  If you are on the latest version and even then if it takes 30mins for changes to take affect, then I would suggest having a look at your management server for the load. 

L2 Linker

What model PA do you have?

Retired Member
Not applicable

30 minutes to commit a change is definitely too long. PAN-OS versions as well as hardware platforms can definitely see differences in management plane performance. 4.1 has in general seen much improved management plane performance for many customers. However, on any platform 30 minutes is not expected. 

One recommendation is if you are using application-filters in your configs, that can cause longer time during the config validation stage. So best to avoid application filters if not absolutely needed. Otherwise should open a case with TAC to have the commit time looked into.


That seems a bit silly, if application filters are a potential problem omitting them is the only answer? I have quite a few application filters setup and they work very well and I like the flexbility of them..

I have had the process committing for up to 15 mins worse case, but the management CPU does get a bit high at times.

We use a PA500 and each iteration of s/w has made the commit process get longer, I know the commit process is complicated that I accept but taking a longtime can be a pain..


Which version of PANOS do you use then?

Commiting a somewhat clean setup (inlcluding threat prevention and url categories etc) on 5xxx boxes took just seconds with 4.1.x compared to older versions of PANOS.

It would be interresting to see "guidelines" in case one think commiting takes too long for what one can check for.

If you have riddicolous large app filters then I can understand why it will take a few more seconds to compile the security rules but at the same time this is the point of using app filters.

Will for example disabling "rematch flows to new security rules" (or whatever that setting is named) change the speed of commits? Or is the commitspeed purely a mgmtplane thing to compile the code which the FPGA/ASIC will be loaded with?

I too would like to chime into this discussion.  I worked through an issue last night where the only changes I was making were renaming some of my static routes.  I went through 6 commits and it took me over 4 hours to get the job done.

Serial #xxxxxxxxxxx
Software version4.1.0
GlobalProtect Client0.0.0
Application version292-1294
Threat version292-1294
Antivirus version681-931
URL Filtering version3809
GlobalProtect datafile version0
TimeWed Feb 29 13:17:07 2012
Uptime92 days, 14:14:54

I have:

  • 47 security policies
  • 25 NAT
  • 275 address objects
  • 58 address groups
  • 0 user defined applications
  • 14 application groups
  • 0 application filters

I takes an average of 10 minutes, minimum to do just a simple, one item change/commit.  Way too slow for modern times.  Should I open a support ticket - or is this just the new PaloAlto?

Please open a ticket.  I have seen up to 10 minute commits for only the first time a new custom application or vulnerability signature is being compiled into the FPGA.  If there are no changes to the signature, subsequent commits should not take that long.

There might be another process running in the background of the management plane that is using the resources.  That said, the PA-2000 series management plane is much slower than the PA-4000 and PA-5000 seriies.



Committing changes on 3.1.x on my 2020s is nerve-wracking during an outage or when I mistakenly change something I didn't mean to change.  (Not that it ever happens...)

Commits on 4.1.x are a lot faster on one of my yet-to-be-deployed 500s, but I have other bones to pick with that series.  (Anyone else see commit failures, especially when leaving out policy and object changes?)  It's a very ambitious dynamic web GUI.  The devs have done a pretty good job with it, but it's not as solid as 3.1.

At least it's not Java.  Please don't go there.

@ Nwallette,

Commit failures while creating objects or security rules has been identified as a bug in the code.  It will be fixed in version 4.1.4 which is due in a month's time.

I agree, Please don't go the Java route!

  • 12 replies
  • 101 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!