Most small teams do not have an error problem so much as a list problem. There are hundreds of lines, most of them the same fault repeated, and no clear idea which one to pick up on Monday. Triage turns that list into a short queue of work. It does not need a scoring model. Four questions and one written decision will cover most sites and apps.
Start from grouped issues, not raw error counts
A raw count tells you how often a code path failed, not how many separate problems you have. One broken image URL on a product page can produce several thousand lines in a day. Group the repeats first so that each row is one fault, then look at the rows.
If your errors are not grouped yet, do that before anything else. We have written about grouping repeated errors separately, and it is worth reading before you start ranking. If you are still setting up, the first-hour setup post covers the basics. Once each fault is one row, you can ask the four questions below of each one.
Keep the list short while you work. Ten or twenty grouped issues is a manageable pass. If you have more than that, sort by the last-seen date and drop anything that has not fired in a month. It may come back, but it is not competing with live faults for your time today.
Ask how many users it touches
Ask how many people hit the fault, not how many times it fired. An error that fires 300 times for one customer's integration matters, but it is a different conversation from an error that fails for one visitor in twenty.
Check the number of distinct users or sessions affected, and whether the fault sits on a page most people use. A broken link in the footer of a rarely visited page can wait. A broken step in the middle of a busy flow cannot, even if it fires less often.
A useful habit is to write the number down next to the group. 'Around 40 users a week, all on the old mobile layout' is more useful a month later than 'some users'. It also makes the ranking easier to defend when someone asks why a noisy error sits lower than a quiet one.
Ask whether it blocks sign-in, payment or saving
Some faults stop a person doing the thing they came to do. Put those first. For most web apps the usual three are sign-in, payment and saving. If someone cannot log in, pay or keep their work, the fault is urgent whatever the count says.
Be concrete about the step. 'Checkout is broken' is vague and invites a long search. 'The card form returns a server error on submit for Safari users' tells the person who picks it up where to look first.
This question can also rule things out. A fault in an admin page that only your team uses may be annoying, but it does not block a customer. Say so in the note, so nobody treats it as an emergency.
Ask whether it is new since the last release
A fault that began with yesterday's deploy usually has a known cause, and the fix is often a rollback or a small patch. An older fault that has been quietly firing for months is a different job, and it may be worth deferring until you can look at it properly.
Compare the first-seen date of each group with your release log. If you do not keep one, start now. A dated line for each deploy is enough. Errors that appear straight after a release move up the list, because the release is the most likely cause and the cheapest place to start.
Be careful with older faults that suddenly spike. A traffic change, a campaign or a third-party outage can make an old error louder without anything in your code changing. Check whether the spike lines up with a release or with something outside your control before you assume the code is at fault.
Fix, defer or close, and write down why
Every issue ends in one of three states. Fix it now, defer it with a reason and a date to look again, or close it because it is not a real problem or is already handled. The important part is the note.
A line such as 'deferred: affects one legacy export, under two users a week, revisit after the next release' saves the next person an hour. Without it, the same error comes back in three months and someone starts from zero, possibly with a different opinion about how urgent it is.
Do not leave issues in a fourth state called 'looking into it'. If nobody has a plan for it, it is not being looked into. Either give it a next step or defer it.
Turn the top issue into a task with one owner
Once you have ranked the list, take the top item and make it a task. One task, one owner, one sentence describing the fault and the step that fails. Put the reference to the grouped error in the task, so the person who picks it up has the evidence in one place.
Shared ownership of an error tends to mean nobody picks it up. A single name, even on a team of three, makes the fix someone's job. Leave the rest of the list in place with its notes. You do not need to plan all of it today, and a short queue is easier to finish than a long one.
Repeat the pass when the top task is done, or at the start of each week. Triage is a habit rather than a project. The list will refill, and the questions stay the same.
AperioFlow puts errors and tasks side by side, so the error and the work to fix it sit in one place. The free plan includes 10 monitors, which is enough to try the method on a live site. Start free at https://app.aperioflow.co.uk/#/signup