Exception types and severity reference
Last updated: October 29, 2026
This is a lookup reference for exceptions in Execute: the built-in types, the severity levels, the status and outcome labels you see on an exception, the exception filters, and the fields on your organization's own exception types. It doesn't walk through raising or resolving an exception — for the mechanics, see How exceptions work, and for the steps, the task articles linked at the bottom.
Exceptions appear only when exception handling is on for your organization; see Exceptions at a glance.
Built-in exception types
These are the types Nash provides. By hand means you can pick the type in the Add exception dialog. Auto severity is what the exception gets when nobody picks a severity — the default for every driver report and route event, and for the Auto option in the dialog.
| Type | By hand | What raises it automatically | Auto severity |
|---|---|---|---|
| Late departure | Yes | The driver starts the route 15 minutes or more after its planned start | P0 at 30+ minutes late or 3+ stops at risk; P1 at 15–29 minutes; P2 under 15 minutes |
| Vehicle breakdown | Yes | The driver selects Report Breakdown in the driver app | P0 when a remaining stop's delivery window closes within 30 minutes; otherwise P1 |
| Customer not home | Yes | The driver fails a drop-off because the customer wasn't home — one exception per delivery at the stop | P3 on the first attempt; P2 on the second; P1 on the third or later |
| Vehicle overweight | Yes | The driver selects Report Overweight in the driver app | P1 |
| Vehicle oversize | Yes | The driver selects Report Oversize in the driver app | P1 |
| Refuel request | Yes | The driver selects Request Refuel in the driver app | P2 |
| Break compliance violation | Yes, on a route with a scheduled break | The vehicle moves during a scheduled break on the driver's shift | P2 |
| Ad-hoc break | Yes | — | P1 when the break pushes a remaining stop past its window; otherwise P2 |
| Catchment violation | Yes | — | P2 |
| Order cancellation request | No — use Request Cancellation on the order | Someone selects Request Cancellation on an order on a live route | P2 |
| Workflow | No | A workflow's Create route flag action, when it doesn't name one of your exception types | The severity set in the action, otherwise P2 |
| Unclassified | No | A workflow names an exception type that no longer exists; the exception keeps the original type key in its details | The severity set in the action, otherwise P2 |
The Nash built-in types list on the exception-types settings page also shows a few more types. They aren't raised in standard Execute operation, so they aren't listed here.
Your organization's own types work like the built-ins. Raised by hand on Auto, or by a workflow that doesn't set a severity, they take the type's Default severity.
Severity levels
| Severity | Label | Meaning |
|---|---|---|
| P0 | Critical · P0 | Needs immediate action |
| P1 | High · P1 | Action recommended |
| P2 | Medium · P2 | Monitor |
| P3 | Low · P3 | Informational |
| — | No severity | An older exception recorded without a severity. Everything raised in Execute today has one. |
Severity drives three things on the page:
- Queue order. With exception handling on, the routes table sorts by Severity by default, most severe first. A route's Exception cell shows its most severe open exception, with the oldest winning a tie.
- The page header. The status next to Operations reads Critical exceptions open when any open exception is P0, High-severity exceptions open when the worst is P1, and All clear when nothing open is P0 or P1. The line beside it counts the routes with open exceptions.
- The severity filters. The row of severity filters narrows the table to one or more levels; Clear severity removes them.
Status labels
| Status | Open? | What it means |
|---|---|---|
| Needs Triage | Open | New; nobody has looked at it. Every exception starts here. |
| Acknowledged | Open | Someone has seen it and is working it. |
| Resolved | Closed | Done. It moves to the route's Resolved section and its details are read-only. |
In an exception's Status field you'll also see Nullify · false alarm. It isn't a fourth status: it resolves the exception and records the note Nullified from triage.
How an exception closed
Open a resolved exception from the Resolved section of the route's Issues tab to see how it closed. The record shows Resolved by and the person's name when someone resolved it, when it was Last updated, any Resolution Notes, and one of these outcomes when one applies:
| Outcome | When you see it |
|---|---|
| Closed when the route ended | The route was completed, canceled, archived, or deleted while nobody had taken the exception. The note names how the route ended. |
| Exception type changed | Someone changed the exception's type. A new exception of the new type replaced it. |
| Re-optimized | An Order cancellation request closed when someone accepted and applied the re-optimized plan. |
A person resolving an exception from its details records their name and no outcome label. A false alarm shows the note Nullified from triage.
Exception details
Opening an exception shows what was recorded when it was raised and the fields you can change.
| Field | What it shows |
|---|---|
| Severity | The current level, P0–P3. |
| Detected | When the exception was raised. |
| Customer impact | How many customers the problem affects, where Nash can count them — for example, the stops at risk on a late departure or the affected customers on a breakdown. |
| Type-specific details | What the source recorded — Planned start, Delay, and At-risk stops on a late departure; the breakdown location and affected stops on a vehicle breakdown; the attempt number on a customer-not-home. |
| Notes | Anything entered when the exception was raised. |
The editable fields, under Exception details:
| Field | What it does |
|---|---|
| Exception type | Changes the type to one of your organization's own types. Shown only when your organization has its own types. Closes this exception and opens one of the new type with the same severity, status, notes, and assignee. |
| Status | Needs Triage, Acknowledged, Resolved, or Nullify · false alarm. |
| Severity | P0–P3. |
| Assignee | A teammate, or Unassigned. Applies to every open exception on the route. |
Select Save changes to apply them, or Discard to drop them.
Exception filters
With exception handling on, the Filters panel has an Exceptions group:
| Filter | Narrows the table to routes with |
|---|---|
| Severity | Open exceptions at the chosen levels |
| Trigger Type | Exceptions of the chosen types, built-in or your own |
| Exception Status | Exceptions in the chosen statuses |
| Assignee | Exceptions assigned to the chosen people, or Unassigned |
Your exception types
Your organization's catalog lives under Settings ▸ Preferences ▸ Exceptions ▸ Manage exception types. Each type has these fields:
| Field | Rules |
|---|---|
| Name | What everyone sees in Execute. Up to 200 characters. |
| Type key | The identifier workflows use to raise the type. Lowercase letters, numbers, and underscores, starting with a letter; it can't reuse a Nash built-in key. It can't be changed after the type is created. |
| Description | When your team should use this type. |
| Default severity | The severity the type gets when nobody picks one. |
| Color | The color the type shows in Execute. |
The page lists your types with their Type key, Description, and Default severity, and shows Nash's built-in types and the Unclassified fallback as read-only. Show archived brings archived types back into the list. Archiving a type hides it from every picker, and existing exceptions keep it in their history; a type a workflow still uses can't be archived until the workflow is changed.
Related
- How exceptions work — sources, Auto severity, the status lifecycle, route-wide assignment, and auto-close.
- Add an exception to a route
- Triage and resolve exceptions
- Assign exceptions
- Manage exception types