Last updated March 25, 2015.


Critical bugs include those that:

  • Render a system unusable and have no workaround.
  • Cause loss of data.
  • Expose security vulnerabilities.
  • Cause tests to fail in HEAD on the automated testing platform, since this blocks all other work.

Regressions in functionality are not automatically considered critical. Even if the bug existed before, it should be prioritized according to its impact.


Drupal core release managers may identify certain strategically important non-bugs as release blockers for a particular release; e.g.:

When a core maintainer decides that an issue should not block a release, its priority is downgraded accordingly.

Impact of critical issues on releases

Major versions of Drupal core (like 7.0 or 8.0) won't be released until all critical issues are fixed.

For point releases of Drupal core (like 7.1 or 8.0.1), outstanding critical bugs will not necessarily hold up a core release. If there are 20 critical issues when 8.0.2 is released, and five of those are fixed, then it may make sense to release 8.0.3 with the other 15 critical issues open - or there may be a security release that has to go out anyway.

In contributed projects, it is up to each maintainer how they handle the critical status.


Issues that have significant repercussions but do not render the whole system unusable (or have a known workaround) are marked major.

An example would be a PHP error which is only triggered under rare circumstances or which affects only a small percentage of all users. These issues are prioritized in the current development release and backported to stable releases where applicable.

Major issues do not block point releases.

For Drupal core 7 and 8, this also applies to test failures in secondary environments.


Major priority is used for tasks or features (code refactoring, performance or usability improvements, etc.) which are important by community consensus, but which are not functional bugs.


Bugs that affect one piece of functionality are normal priority.

An example would be the category filter not working on the database log screen. This is a self-contained bug and does not impact the overall functionality of the software.


Minor priority is most often used for cosmetic issues that don't inhibit the functionality or main purpose of the project, such as correction of typos in code comments or formatting/whitespace issues.

Choosing the right priority

Feature requests are very rarely "critical". They should usually be "normal".

Support requests should never be marked "critical" or "major". If you believe you have run into a bug and it is preventing your site from working at all, post it as a bug report; however, be prepared for others to re-categorize it as appropriate. A higher issue priority is unlikely to give you better support; it is better to describe your issue thoroughly (with clear steps to reproduce it) to help people understand what is wrong.


Wolf_22’s picture

Support requests should never be marked 'critical' or 'major' - if you believe you have run into a bug and it is preventing your site from working at all, post it as a bug report, however be prepared for other users to recategorise it as appropriate.

If Support Requests are never to be marked as "critical" or "major", then it might be best to add a restriction somewhere that disables those options if and only if the user selects "Support Request" as their Category.