> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kitospace.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Availability Exceptions

> Block dates from being booked with availability exceptions — closures, holidays, maintenance, and recurring downtime for a whole workspace or a single unit.

## What is an availability exception?

An availability exception is a date range you close off so that no reservation can be booked in it — a public holiday, a renovation, annual leave, or any period a room or space is simply not available. A booking that lands on those dates is rejected outright, and the guest is emailed the reason.

Every exception applies either **workspace-wide** — every unit in the property — or to **a specific unit**.

## How do I create an exception?

Open **Settings → Availability Exceptions** and click **New exception**. You can also start from the **Availability Exceptions** card on a unit's settings page, which creates one scoped to that unit.

<Steps>
  <Step title="Give it a label">
    The **Label** is internal — only you and your team see it. It is how you will recognise the closure in the list, for example *Annual Maintenance*.
  </Step>

  <Step title="Add a guest message (optional)">
    The **Guest message** is included in the rejection email, so use it to explain the closure or point the guest at alternative dates.
  </Step>

  <Step title="Choose what it applies to">
    Under **Applies to**, pick **All units** for a workspace-wide closure or **A specific unit** to block just one room or space.
  </Step>

  <Step title="Pick the dates">
    Set a start and end date. Use **Add another date range** to cover several separate periods with the same exception.
  </Step>

  <Step title="Set recurrence (optional)">
    Choose how often the closure repeats. Leave it on **Does not repeat** for a one-off.
  </Step>
</Steps>

## What happens to existing bookings?

If the dates you chose overlap reservations that are already in the system, Kitospace shows you those conflicts before anything is saved:

| Conflicting reservation | What happens                                          |
| ----------------------- | ----------------------------------------------------- |
| Has not started yet     | Cancelled, and a rejection email is sent to the guest |
| Already in progress     | Left untouched — never cancelled or modified          |

You can also confirm the exception while keeping the conflicting reservations, in which case the closure is created and the existing bookings stand.

<Note>
  Every new booking is checked against your active exceptions before it is accepted, and the check is inclusive of both the start and end date. A stay that touches even one blocked day is refused, and nothing is saved. Workspace-wide exceptions block every unit; unit-scoped ones block only the unit they name.
</Note>

## How does recurrence work?

A recurring exception repeats the same date ranges into the future, so you only set it up once.

| Recurrence      | Repeats                                       |
| --------------- | --------------------------------------------- |
| Does not repeat | One-off — the dates you entered, nothing more |
| Weekly          | Every 7 days                                  |
| Monthly         | Every calendar month                          |
| Custom interval | Every *N* days, where you choose *N*          |

With **Custom interval** you must fill in **Repeat every (days)**. If that number is left empty or is zero, only the original date ranges block bookings.

## What does the guest receive?

When a booking is refused, the guest gets a rejection email containing:

* The reason for the rejection, taken from the exception's label
* Your guest message, when the exception has one
* The dates they requested
* Your property name and contact email, so they can reply

Bookings that arrive by email import are handled the same way: the conflicting booking is skipped, the guest is emailed, and the rest of the import continues normally.

## Managing your exceptions

The **Availability Exceptions** page lists every active exception with its dates, scope, and recurrence. Filter by **All**, **Workspace-wide**, or **Unit-specific**, and narrow further to a single unit. A unit's own settings page shows its exceptions plus the workspace-wide ones it inherits.

<Tip>
  Create closures at the workspace level whenever they affect the whole property — a public holiday or a full shutdown. Reserve unit-scoped exceptions for cases where one room genuinely differs, such as a single apartment under repair.
</Tip>

<Warning>
  Deleting an exception reopens those dates for booking immediately. Use the **Undo** action in the confirmation toast if you removed the wrong one.
</Warning>

## Common use cases

* **Seasonal shutdown** — block a workspace-wide range over the off-season so nothing can be booked.
* **Room out of service** — close one unit for repairs while the rest of the property keeps selling.
* **Weekly closing day** — a weekly recurring exception keeps the same day blocked indefinitely.
* **Owner stays** — block the dates an owner uses the property themselves.

## Related

* [Reservations](/docs/reservations/overview)
* [Calendar](/docs/reservations/calendar)
* [Units](/docs/units/overview)