Child pages
  • LexoRank Management
Skip to end of metadata
Go to start of metadata


As of JIRA Agile 6.7.0, there is now a LexoRank Management section. LexoRank is the name for the new ranking system as of JIRA Agile 6.4.0 and higher, which provides the ability to rank issues in JIRA Data Center - this functionality is also used in normal JIRA Server installations. The user interface can be found in Administration > Add-ons > Lexorank management. It provides a user interface for several of the key areas of LexoRank administration.

In prior versions the way to retrieve this information was to directly access REST endpoints, and read the JSON that was returned. This UI now handles that approach for the user.


As per the above screenshot, the UI provides the user with details on the distribution of issues in each bucket, and whether or not a balance is in progress or if it is disabled. Running a balance is similar to running a re-index of JIRA, there isn't any guarantee it will fix a problem unless the problem is specific to the ranking data. If you're encountering issues and don't know why, and are unsure whether or not to balance, review the integrity checks first and contact support if need be as per the below details.

A breakdown of the service status is below:

Balancing disabled

If this is true:

  • A foreground re-index may be running. It is expected that this will disable balancing.
  • JIRA Agile may have just been installed / upgraded and requires a reindex.
  • Check the logs for any exceptions and see if there are existing KB articles for these errors.
  • See if there is anything failing in the Integrity checks.
Balance handler running
  • This will be false unless a balance is currently in progress. To verify the progress of the balance, hit the refresh button.
  • On a JIRA Data Center cluster this will be true on the node that is running the balance, and false on the other nodes.
Balancing in progress on a node of the cluster
  • It indicates that the balance cluster lock has been taken.
  • This will be true when a balance is running.

Current balancing can take quite a long time on larger instances, and there is a fix for this tracked in  GHS-11491 - Getting issue details... STATUS .

Integrity Checks

This runs a series of tests against the LexoRank data and returns a true / false result based on the test. The tests are detailed below.

CheckHow to Fix Failures
Marker rows present in table for rank field.

If this fails, the minimum or maximum marker rows are missing.

This can be caused by GHS-10975 - Getting issue details... STATUS and there is a fix included in the workaround for that bug.

Marker rows correctness check.

If this fails, the minimum or maximum marker rows exist, however have the incorrect rank.

This can be fixed by updating the rank on the row returned in the check to be the expected value.

Marker rows in valid bucket check.

When a balance is in progress, the marker rows are moved to another bucket to indicate where the new rank values should be. The only time they should be is in different buckets is if a balance is in progress.

Valid states for the marker rows are the below.

  • Minimum is the same as maximum.
  • Minimum is 0, and max is 1.
  • Minimum is 1, and max is 2.
  • Minimum is 0, and max is 2.

This test fails if the marker rows are not in those buckets, and is likely caused by exceptions thrown during the rank creation or balance operation. Please check the logs for those and verify them against known problems.

Rank out of bounds check.Please refer to our How to Fix Rank Out Bound Error KB article for the fix.
Duplicate ranks check.This can be fixed as detailed in How To Fix Duplicate Rank Values For a Rank Field.
Issue ranks different from marker ranks check.

The below SQL will identify records that have ranking values the same as the min/marker rows. Deleting these records will correct this problem (and also result in a loss of ranking data for those issues only).

SELECT * FROM "AO_60DB71_LEXORANK" WHERE ("RANK" LIKE '%|zzzzzz:' OR "RANK" LIKE '%|000000:') AND "TYPE" not in (0,2);

(info) This may require changing depending upon the DBMS used.

Issue rows in valid bucket check.If a balance cannot fix this, it would need detailed analysis from Atlassian Support.
Balance status check.Attempt a balance, and check the logs to see if there are any exceptions. It's likely the balance is failing due to a exception in the logs, or one of the other checks above may be failing.

If you're unsure how to proceed, please feel free to contact support for further assistance as below.

Sending Information to Support

Please raise a case at and provide the following information:

  1. Generate JIRA support zip.
  2. The result of rank integrity checks.
  3. An XML backup of your database (Administration > System > Backup System). You can anonymise if you wish by going as per our Anonymising JIRA Data page.
  4. If attaching a backup is not possible, please provide us with the result of the following SQL (preferably in a CSV file format).


    (info) Depending upon the DBMS used, the tablename may be different. For example AO_60DB71_LEXORANK instead of "AO_60DB71_LEXORANK".

Help us improve!
  • No labels