Toast Course Pacing Is Now Dine In Only: Check Each Dining Option's Behavior

From Toast POS 2.117, POS orders on any dining option without the Dine In behavior send every item to the kitchen at once. The option's name doesn't decide it. An audit sheet, a fictional Patio example and the cases Toast's pages don't cover.

Ryan Speier

Quick answer: Starting with Toast POS 2.117, course pacing only applies to orders whose dining option uses the Dine In behavior. Toast's October 9, 2026 announcement says orders with any other dining behavior now send all items to the kitchen at once, without courses. Before this change, every order placed in the Toast POS app was course-paced, whatever its dining option. So if takeout or delivery tickets suddenly hit the line all at once, that's the documented change, not necessarily a broken setting. To check a custom option, look at its Behavior, not its Name. An option called "Patio" that's set to Takeout behaves like takeout. Don't flip it to Dine In just to get pacing back, because the behavior also tells the kitchen whether to plate or package.

This guide is based on Toast's public documentation, read October 14, 2026. We didn't run it on a Toast account or device. The expected results below come from Toast's pages. The observed result in the audit sheet is for you to fill in.

What Toast changed, and what the announcement doesn't tell you

  • The change: Course pacing used to apply to every order placed in the Toast POS app, so takeout and delivery orders also went to the kitchen one course at a time. Now it applies only when the order's dining option uses the Dine In behavior (Toast announcement).
  • Version: The announcement says the change is "first available in Toast POS version 2.117." Its header is tagged Generally Available, All Locations, POS v2.117, and it lists affected countries as All.
  • Date: October 9, 2026 is the date Toast posted the announcement. It isn't proof of when your devices got 2.117. Check the version yourself rather than assuming.
  • Corroboration: Toast's current Dining options guide and its course pacing settings reference both carry the same note: course pacing only applies to dining options that use Dine In behavior.

Send, fire and fulfill are three different things

Toast's reference says course pacing "separates the send and fire actions." An order can be sent to the kitchen with later courses held, and those courses fire when a server, the expediter or an automatic rule releases them, depending on your settings. Fulfilled is a later status someone taps when food is done.

This change is about whether an order is coursed at all. On a coursed order, what reaches the kitchen first depends on your Sending Courses setting: if it's set to send all courses immediately, every course can reach the kitchen at once, and your Firing Courses setting decides whether later ones show as held or fired. On a non-Dine In order on 2.117 or later, Toast says all items go to the kitchen at once, without courses. A ticket showing up on the line doesn't mean the food is ready. Turning course pacing on or off won't fix a takeout order that was bumped early or a guest text that went out too soon. Those are covered in our Toast KDS multi-select guide and our order-ready texts guide.

Name versus Behavior: the setting that decides it

In Toast, every dining option has two fields that matter here:

  • Name is what staff see on order screens and on printed or KDS tickets. You can call an option anything.
  • Behavior is one of Toast's predefined types: Dine In, Takeout, Curbside, Delivery or Drive-thru. The settings reference also lists None. Toast says behavior tells the kitchen whether to plate or package the food, and some platform features vary by it.

Behavior also changes what an order asks for. Toast's support article on custom dining options says Dine In supports table numbers and server assignments, Takeout requires customer information, and Delivery requires customer and delivery information. Name and Behavior are separate fields. You can edit a dining option's Name, including on Toast's pre-populated options, but its Behavior is selected from Toast's predefined list, not renamed. Renaming an option doesn't change its behavior. Toast's pre-populated options show why the name isn't enough: one is named Take Out, while its behavior is Takeout. A custom option named "Bar," "Patio," "Counter" or "Catering" tells you nothing about pacing until you check its behavior.

Where to look: Kitchen > Dining options > Dining options in Toast Web. Toast's Dining options guide says you need the Web setup > Kitchen / Dining Room Setup access permission to view and configure dining options. The same page sets the restaurant-wide Default option, and an individual POS device can override that default with its Device Default Dining Option setting under Setup > Device Setup (Dining Options settings). Toast's support article lists the 7.1 Terminal Set-up permission for that device setting. It matters because two terminals can start orders on different options without anyone choosing one.

What to expect from a POS order now

This table covers only an ordinary order placed in the Toast POS app, on a device you've confirmed is on 2.117 or later, with course pacing enabled at Kitchen > Pacing > Meal pacing. If the version or the pacing setting is unknown, or the version is older, don't use the table.

Order's dining optionExpected kitchen dispatchSource
Any option with Dine In behavior, including a custom one such as "Bar"Paced by course, following your Sending Courses and Firing Courses settingsAnnouncement; settings reference
Options with Takeout, Delivery, Curbside or Drive-thru behavior, such as the default Take OutAll items sent to the kitchen at once, without courses. Before 2.117 these were course-paced.Announcement
A custom name on a non-Dine In behavior, such as "Patio" set to TakeoutSame as the row above. The name doesn't change it.Announcement; Toast's own Patio example
Not confirmed: see the list belowNot documented on the pages we read. Confirm with Toast before you tell staff what to expect.No supporting page found

Outside the confirmed matrix. None of the Toast pages we read says how the course pacing change applies to these cases, so don't promise staff a result:

  • An option with the None behavior. The announcement's "any other dining behavior" wording suggests no pacing, but no page we read addresses None directly.
  • An order where one item carries a different dining option than the rest. Toast says dining options can apply to a whole order or a single item.
  • Changing an order's dining option after part of it has been sent.
  • An order sent with no dining option assigned. Toast's support article says those orders show up under None in sales reports, which is a reporting label, not the None behavior.
  • Toast Online Ordering, orders placed through an integration partner (the API setting), and orders scheduled for a future date (the Future setting). The announcement describes orders placed in the Toast POS app.
  • Any order whose origin you can't confirm. An option's API or Future flag shows what the option is set up for, not where a particular order came from.
  • A location where some devices are on 2.117 and others aren't.

Fictional example: the patio that gets takeout containers

Harbor Street Bistro is a made-up restaurant. Toast's own settings reference uses this setup as its example: an outdoor patio where the kitchen packs food in takeout containers, so the location creates a Patio option with Takeout behavior.

The bistro's options are Dine In (Dine In behavior, the restaurant default), Take Out (Takeout), Delivery (Delivery), Bar (Dine In) and Patio (Takeout). Course pacing is on. Sending Courses is set to send all courses to the kitchen immediately, and Firing Courses is set so the server fires each course.

A patio guest orders calamari as a starter and a burger as a main. Here's what the documentation leads you to expect. These are expected results, not something we recorded:

  • Before 2.117: if the server fires only the starter, the calamari fires and the burger waits as a held course until the server fires it.
  • On 2.117 or later: Patio uses Takeout behavior, so both items go to the kitchen at once, without courses. The grill could start the burger while the calamari is still in the fryer.
  • The same order rung on Bar: still coursed, because Bar uses Dine In behavior even though nobody named it "Dine In."

The tempting fix is switching Patio to Dine In. Don't do that just to get pacing back. Patio is set to Takeout because the kitchen packages that food. Change the behavior and you've also changed what it signals and what the order asks for: per Toast's support article, Takeout requires customer information and Dine In supports table numbers and server assignments. The settings reference documents two more things tied to behavior: guest details printing on takeout and delivery tickets, and KDS ticket colors by dining behavior. Also check any item routing rules that use the dining option as their condition.

The manager's actual question is how the patio really runs. If patio food leaves in containers and comes out together anyway, keep Takeout and tell the kitchen to expect patio tickets all at once. If the patio has turned into plated, coursed table service, then a Dine In behavior may match reality. Make that change on purpose, after checking the side effects above and testing it the way your restaurant already approves. If neither fits, take it to Toast before you change anything.

Copyable audit sheet

Copy the option block once for each dining option. Note any device whose default differs from the restaurant default. Leave the observed result blank until someone actually checks it.

TOAST DINING OPTION AUDIT (course pacing, POS 2.117+)
Basis: Toast's public docs, read Oct 14, 2026. Not
tested on any Toast account or device.
Location: ________  Checked by: ________  Date: ________

STEP 1 - STOP GATE (fill in before anything below)
POS version, read on the device: ________
Verified 2.117 or later? Y / N / UNKNOWN
Course pacing enabled? Y / N / UNKNOWN
Sending Courses: ________  Firing Courses: ________
If the version is older or UNKNOWN, or pacing is N or
UNKNOWN: STOP. The expected results below don't apply.

STEP 2 - ONE BLOCK PER DINING OPTION
Option name:
Behavior (exactly as in Toast Web):
Restaurant default? Y / N   Device defaults using it:
Option flags: Future? Y / N   API? Y / N
  (Flags show how the option is set up. They don't
  prove where a particular order came from.)
Intended real service (plated / packaged / mixed):

STEP 3 - ONE LINE PER ORDER YOU CHECK
Actual order origin (POS app / online / API partner /
  scheduled / unknown): ________
NOT DOCUMENTED - ask Toast, don't predict - if any:
  [ ] online order           [ ] API/integration order
  [ ] Future/scheduled order [ ] origin unknown
  [ ] None behavior          [ ] no option assigned
  [ ] item-level option, or mixed options on the order
  [ ] option changed after part of the order was sent
  [ ] devices at this location on mixed POS versions
Only if Step 1 passed and it's an ordinary order
placed in the Toast POS app:
  Dine In behavior: paced per Sending/Firing settings
  Takeout, Delivery, Curbside or Drive-thru behavior:
    all items at once, without courses
Expected result: ________
Observed result (blank until tested): ________
Discrepancy:
Owner who decides:

For Harbor Street Bistro, Step 1 passes only once someone has read 2.117 or later on the patio device and confirmed course pacing is on. Then, for an ordinary patio order rung in the POS app, the expected result is "all at once" and the discrepancy is "kitchen used to course patio orders, staff not briefed." The owner is the general manager. A patio order that came in online or through a partner gets NOT DOCUMENTED instead, even though it's the same option. The observed result stays blank because nobody has checked it on a device yet.

Check it before a shift

These are proposed checks. We haven't run them.

  1. Confirm the POS version on each device. The change is first available in 2.117. If you can't confirm it, stop there: the matrix doesn't apply.
  2. Open Kitchen > Pacing > Meal pacing. Write down whether course pacing is enabled and what Sending Courses and Firing Courses are set to. Toast's reference lists the same Kitchen / Dining Room Setup permission for this page.
  3. Open Kitchen > Dining options > Dining options. Copy every option's Name and Behavior into the audit sheet exactly as shown, plus the Default, Future and API flags. Those flags show how an option is set up, not where a given order came from.
  4. On each POS device, note Device Default Dining Option if it's set.
  5. Write the real service for each option, then compare it with the expected column in the matrix above. Mark anything that's NOT DOCUMENTED instead of guessing.
  6. If you want to see it on the line, use only a test procedure your restaurant already approves. Use made-up item notes and no guest names, phone numbers or real payments. Don't place surprise paid orders or text anyone. Record what the kitchen screen or printer actually showed.

When the kitchen sees something you didn't expect

  • Write down the current settings before any change. Note the option, its behavior, device defaults and pacing settings, so an authorized person can put them back.
  • Check the course assignments first. Toast's reference says an item with no course is listed under a "No Course" heading, and in two of the three Firing Courses options that course fires immediately. A Dine In order can look unpaced simply because its items were never assigned courses.
  • Separate a misconfiguration from an unclear case. If the behavior is wrong for the service, that's a decision for the manager. If the order falls into the not-confirmed list, that's a question for Toast.
  • Stop changing settings that don't relate to it. Routing, ticket and fulfillment settings are separate mechanisms. Changing them to chase this one adds new variables.
  • Know what a rollback can't undo. Putting a setting back doesn't pull back tickets already sent or fired, or a guest message already delivered.
  • Bring Toast the facts. Use your restaurant's normal support process and include the POS version, option name and behavior, device default, pacing settings, the time, and a photo of the ticket with any guest details covered.

What staff need to know

A short pre-shift note, written for the kitchen and servers:

COURSE PACING CHANGED (Toast POS 2.117+)
Based on Toast's docs. Not tested on our devices.
Applies only if the manager has confirmed this device
is on 2.117 or later, course pacing is on, and it's an
ordinary order rung in the Toast POS app. If not, or
if nobody knows, don't expect either result. Ask.
- Dine In behavior options: coursed per our settings.
- Takeout, delivery, curbside and drive-thru behavior
  options: everything at once. That's expected now.
NOT CONFIRMED. Ask the manager, don't guess:
- online, API/integration or scheduled orders
- orders when you don't know where they came from
- None behavior, or no dining option on the order
- an item on a different option, or mixed options
- option changed after part of the order was sent
- devices on different POS versions
ALWAYS:
- The name on the ticket isn't the behavior. "Patio" can
  be takeout. Ask the manager if you're not sure.
- A ticket on the screen doesn't mean the food is ready.
- See something odd? Don't change settings on the line.
  Tell the manager on duty, who checks the
  option's behavior.

One detail for the line: the dining option name may not appear on every ticket. If Always Print and Show Dining Option is set to No, tickets for the restaurant's default option leave it off.

Who decides what

Owner: Decide whether any custom option's behavior no longer matches how that area really serves guests. Manager: Run the audit, brief the kitchen and change a behavior only on purpose, after the side-effect check. Staff: Read the option on the ticket. Expect all items at once only when the manager has confirmed the device is on 2.117 or later and course pacing is on, the order is an ordinary one rung in the Toast POS app, and its option has Takeout, Delivery, Curbside or Drive-thru behavior. If the version or the pacing setting is unknown, or the version is older, don't expect either result. Don't predict anything for online, API, Future or scheduled orders, unknown origin, None behavior, no option assigned, an item on a different option or mixed options, an option changed after part of the order was sent, or devices on mixed POS versions. Take those, and anything unexpected, to the manager.

Sources

All four were read October 14, 2026. For where online orders land, see our Toast online ordering location confirmation guide.

More on technology

All technology posts · Free restaurant calculators · Opening planner