If I tell you drinking coffee is "priority one" for me; I am reasonably sure you will assume that is it very important for me to drink coffee. But is it logical to think of a low number as a high priority; or is it simply a cultural bias?

The question occurred while considering a system that requires tasks where fine grained control is needed when adding new tasks. Here we express priority as a number, and things are not so "intuitive" anymore. When you say 'a higher number has a lower priority'; it sounds like an inverted way of thinking.

I would have liked to stick to some standard. But unable to find such a thing I looked around for examples. Thus, I came across MS-Project. Their choice seems to be more logical (albeit less "intuitive" to me): a higher number has a higher priority.

It is easy for me to imagine my tasking system will one day exchange tasks with MS-Project; so I am leaning towards picking the MS-Project way. And thus, adopting their's as a de facto standard.

I also have internationalization needs (like many of us). Am I making the right choice?

  • 1
    I have used several computer systems where priority increased with increasing number. The old Xerox Sigma 7 OS, IIRC, had priorities 0-7 with 7 being the most urgent.
    – Hot Licks
    Commented Feb 11, 2015 at 18:28
  • 1
    There is not a standard. If I saw a 1-4 I might be inclined to think 1 is high. But if I saw a 1-10 I would be more inclined to think 10 was high. What ever you decide you need to make is clear in the UI and documentation and be consistent. Even something like history - is 1 the last one you did or the first one?
    – paparazzo
    Commented Feb 11, 2015 at 19:59
  • 3
    Just a side note - all UNIX-based OS's use lower numbers to indicate higher priority for processes. Indeed, one can even get negative priorities. This is confusing, but just another widely-used benchmark. See nice(1)
    – felixphew
    Commented Feb 11, 2015 at 20:04
  • After all the great answers, I now feel obliged to share my more informed opinion: I feel that the meaning you tie to the smaller number is driven by the domain of your end-users. Researching and finding examples are very helpful if you want to form an opinion about how your users will think about these numbers. (i.e. a unix job scheduling application vs. an app that exchanges info with MS Project). That said; it should be noted that the user experience is much better when you do not use a number -- thus making the answer to this question not relevant.
    – Willem
    Commented Feb 14, 2015 at 6:54
  • The main issue here is the ambiguity of the term “priority”. If you’re designing a new system, you might as well chose a clearer term, e.g. “weight” or “severity” both fall naturally into the higher=higher category.
    – Carsten
    Commented Apr 15, 2020 at 12:22

9 Answers 9


There seems to be no set universal standard, only standards within different regimes picking a standard of increasing or decreasing priority. That said, a lower number being the highest priority appears to be more common. For example, Listing priority number, within the United States Fish and Wildlife Service uses a lower number to denote a higher priority.

Risk Priority Numbers use a higher number to denote higher risk.

The RPN is not a measure of risk, but of risk priority . You would apply your limited resources to the most important problems. The RPN gives you a model to allocate these resources. Higher numbers are higher priority, so you should work on an RPN of 900, before you put resources on an RPN of 30.

A good study of increasing priority numbers is Solving Queueing Systems with Increasing Priority Numbers J.-C. Panayiotopoulos The Journal of the Operational Research Society Vol. 31, No. 7 (Jul., 1980), pp. 637-646

Basically, when it comes down to it, there is no right or wrong answer. The choice is up to you - just ensure that you make it clear if you are using higher or lower numbers to denote higher priority.

One thing to note is that if you use the lower number being the highest priority, then you set an absolute limit, or ceiling, to the priority. If a new event/item comes along which over rules all prior events/items in the list, including those already at priority one then what do you do. Demote all events/items in the list? An ugly solution. So, it could be better to use a higher number denoting a higher priority. That way the list can always accommodate a new super high priority. That said, then very lower priority events/items may all end up getting bunched in the priority one category together, when some obviously will still have an intrinsically higher priority than others also at priority one. However, this is less of an issue, as they are all low priority and can be reprioritised at a later date.

  • Technically, if the software is built to recognize integers (as it should be) as valid priority values, there is no upper or lower limit as negative values would be perfectly fine.
    – dnbrv
    Commented Feb 11, 2015 at 16:11
  • 4
    Technically, I agree - but a negative priority looks odd, and using a negative priority to denote higher priority would seem a bit wrong, in a lower-number-high-priority system. Commented Feb 11, 2015 at 16:18
  • Oh, yeah, my bad.
    – dnbrv
    Commented Feb 11, 2015 at 16:24
  • 1
    Marked this as correct because it expanded my view. However I do not thereby suggest that the other answers are incorrect.
    – Willem
    Commented Feb 14, 2015 at 6:57
  • Good answer. One can also get the opposite problem with an open end on the other side. Speaking from WordPress dev, where your plugin can live in an ecosystem with an arbitrary number of other plugins, it was refreshing to know you could set a filter's priority to 1 to ensure it happens in the first round. But if you want to ensure you come after everything else, so that nothing can accidentally reverse your changes, you'd sometimes see people doing priority 1,000 or 10,000 or other ridiculous things — and others are forced to escalate quickly since you don't know where the bar will be set. Commented Nov 8, 2021 at 11:41

I would answer your question with a big YES!

Let me back that up by showing you what the DEFCON alert state does, since that's about as important as it gets when it comes to priority.

From Wikipedia:

The defense readiness condition (DEFCON) is an alert state used by the United States Armed Forces. The DEFCON system was developed by the Joint Chiefs of Staff (JCS) and unified and specified combatant commands. It prescribes five graduated levels of readiness (or states of alert) for the U.S. military, and increase in severity from DEFCON 5 (least severe) to DEFCON 1 (most severe) to match varying military situations.

* Emphasis is mine



Here are the 5 levels of DEFCON :

level colors

DEFCONs vary between many commands and have changed over time, and the United States Department of Defense uses exercise terms when referring to the DEFCONs. This is to preclude the possibility of confusing exercise commands with actual operational commands. On 12 January 1966, NORAD "proposed the adoption of the readiness conditions of the JCS system", and information about the levels was declassified in 2006:

levels table
Click to view table in its full size

  • Nice example. Thanks for bringing it to my attention.
    – Willem
    Commented Feb 11, 2015 at 16:03
  • 3
    Maverick having a DEFCON example somehow seems poetic. Commented Feb 11, 2015 at 17:42
  • @EvilClosetMonkey - Doesn't it though? LoL! My mind immediately went there =D Commented Feb 11, 2015 at 17:44

Priority 1 / Top Priority / First

The number 1 has the unique feature of being the closest whole number to zero.

Rating how important or critical something is should always put 1 first otherwise with only a single priority 8 item I'll have no way to know where it falls on the entire list of priorities.

If 1 doesn't represent the most important priority then there would be no zero reference point and no context to judge any other priority number. Would it be 5, 10, 100, 2 ?

Since I recently built a product measuring both Risk Level and Productivity Rating each with 5 number values on the backend I'll show you what tested well with our users (we chose not to expose the numbers at all in the UI)


  • 1
    Good points. Rating is not really my problem; but having absolute ceiling [top and bottom] is important. The idea of having 1 on top also creates a 'natural' feeling when applied to an 'order-by' column.
    – Willem
    Commented Feb 11, 2015 at 15:57
  • 1
    The closest whole number to zero is zero, technically. Commented Feb 11, 2015 at 19:09

Just like anything else, you have to validate this with your users. If they are project managers and the convention in PM software is to use numbers where greater number equals to higher priority, then stick to that and don't fix what's broken. If they are used to verbal representation (e.g., e-mail flags of High/Low priority), then you'll have to use that.

Alternatively, you can relieve your users of the mentally taxing task of assigning values to indicate priority and instead implement a drag'n'drop interface in the list of tasks where the top tasks will have a higher priority and the value is assigned automatically in the background. Asana does this extremely well.

  • Yes, considering the users as always best; I need to think whether I would classify my application is "PM Software" or not. I have considered your alternative suggestion. Unfortunately those that create tasks do not have access to the lists of those that perform the tasks; so producing such an interface is not feasible. Consequently the priority is more like a policy (i.e. not a relative value).
    – Willem
    Commented Feb 11, 2015 at 15:53
  • @Willem: If users who create tasks are not the same as the users who assign priority, then making it easy for those who assign priority is especially important. Also, it's not clear to me what you mean by "policy". Are you saying that your users don't need 1,000 levels of priority as MS Project offers?
    – dnbrv
    Commented Feb 11, 2015 at 16:06
  • Those creating tasks do set the priority, but they do not always know how the change in priority will affect the workload of the assignee. Yes, it is true. 1000 levels are a bit much. users would typically decide on broad levels (i.e. ranges within the numbers). However having more levels do allow them to tweak things when the need arises.
    – Willem
    Commented Feb 11, 2015 at 16:14
  • Let's focus on the strategy of task assignment. The manager cares that more critical tasks (closer deadline, more dependencies, more resource drain, etc.) get done ASAP. The worker cares to know what the manager needs and that it's displayed prominently. None of them cares about the actual priority value. This means that, in complex projects, priority should be calculated using a formula &, in simple projects, the task list should be sorted with drag'n'drop to float priorities to the top.
    – dnbrv
    Commented Feb 11, 2015 at 16:41
  • DnD would get rid of the concept of the priority. But sometimes it is needed. If manager A and manager B each place a new task for W. On manager A's list the task is on top and on manager B's list his new task is on top. The managers do not have access to W's list (i.e. they cannot see each other's tasks). A priority is needed to determine the order in which W processes the tasks. A policy is an agreement between A and B on how to assign priorities so that W will work on the most important stuff first. Automating policies is not always feasible.
    – Willem
    Commented Feb 11, 2015 at 17:03

Higher-number-higher-priority is better because is natural. It's something you can logically agree without investigating elsewhere.

Why? Because the other is odd, excpecially in certain circumstances.

@Greenonline, the person whose the answer was accepted, says: "but a negative priority looks odd, and using a negative priority to denote higher priority would seem a bit wrong, in a lower-number-high-priority system". In higher-number-higher-priority context, negatives are things you don't mind about, not so much, naturally.

(If everyone in the world does it wrong it's not enough for me to do the same way.)

  • This quite well express my feelings. Consider: "We have to start working on tasks with Highest priority, thas why we select task with lowest number" Its simply odd :) If I can choose I vote for Higher-number-higher-priority sounds really natural to me.
    – bugs_
    Commented May 30, 2019 at 12:25
  • So you're saying it's intuitive that the item numbered 1 in your queue is not the first item to do but the last one, and the item numbered, say, 265 should be done first?
    – cjs
    Commented Jan 7, 2023 at 8:48
  • If you want that the task numbered with 1 is the first, you're talking about "order"
    – Plap
    Commented Jan 8, 2023 at 18:28

Priority is just a case of sorting, because the priority is always based on something. In case that something is a numerical value, you should choose the priority value as that exact value and determine sort order by your use case.

Ascending Examples (lowest first)

  • buying products and services (the client should check the cheapest offer first, the priority number is the amount in your currency of choice)
  • navigation, where cost, length of voyage and/or distance is minimized

Descending Examples (highest first)

  • selling products and services (you want to consider the clients that pay the most first)
  • most often selected before (present the user items first that they most probably are looking for, based on the number of times the items were watched or bought)
  • relevance through network connectivity, such as inbound or outbound degree
  • highest occurrence of some problem-representing number (e.g. sending new doctors where the most sick people are)

If there is no such a sorting key to base your priority on, then I would choose lowest first, because it is more intuitive to sort numbers in ascending order and you have a clear starting point (0, even though it may start at 1).


My two cents:

It is not a cultural bias. The two "number systems" are consistent.

Think of a stack of tasks in an actual plastic or wood inbox (remember those?).

At the top of this stack is the thing you have to do before you can work on the next one.

Therefore your first priority—priority one, job one, smallest number wins—is the first item on top of the stack.

This first priority task (little number) is also by definition the highest priority task (big number), because it is furthest away from the bottom of the inbox.

It is literally "higher up" from the bottom of the inbox than any other task.

Similarly, the lowest priority task (little number) is the one "lowest down" and therefore closest to the bottom of the inbox and will be by definition your tenth or hundredth or last priority (big number).

Now suppose you are adding tasks to this stack, starting with an empty inbox.

The first thing you add—in position one (or zero if you're a computer person)—is at the bottom of the stack. It occupies the lowest position (the smallest one; the one with the smallest number).

The second thing you add is in position two (bigger number). The tenth thing you add is in position ten (even bigger number). The (physically!) highest (priority) thing you add last is, by definition, at the top of the stack in some position that is a really big number.

Anyway that's how the two "number systems" and the language we use to describe them—in English, anyway—interact.

Depending on the system or environment involved, sometimes it makes sense to talk about the position of a task within the stack. When doing this, bigger numbers win, because the task at the bottom of the stack has position one (or zero) (it was added first, not last), and the task at the top of the stack (the highest one) has position…however big the stack is (maybe minus one) (it was added last, not first, and is the highest task on the stack).

Other times it makes sense to talk about how the stack is processed, in which case the task that should be processed first (little number) has position one (or zero) (it's the highest one on the stack), and the task that should be processed last (the lowest one in the stack, the least of your priorities or concerns) has position…however big the stack is (maybe minus one).


I think the simplest logic of High Priority being lowest number that people often start from 1 (or 0) to start recognizing the tasks/things/people in queues. For example, you added your work on a queue or people standing in queue so the work or people get entertained starting from one.

Priority is always associated to Queue! So, that's why it is widely accepted.


I pondered this for a long time while building an application, and thought both made sense. Then I started using my application, and from time to time I wanted to increase the importance of one particular task to make it more important than all the others. When #1 is top importance, where do you go to bump something up higher than other #1 top importance tasks? 0? -1? I did not like that. So, I made higher numbers represent higher importance. My top priority is the highest number in the stack. If I need to bump something way up, it becomes priority 2 and then 3 and so on...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.