---
title: "Slots, holds and reserved slots explained"
slug: video-slots-explained
section: Video Library
status: stable
description: "Imagine 10 engineers all building new features at the same time."
last-updated: 2026-10-07
---

# Slots, holds and reserved slots explained

Video: Slots, holds and reserved slots explained (2:06) — /docs/video-slots-explained

- Answers: How do deploy slots, holds and reserved slots work
- Audience: engineering; program scope: all programs
- Visibility: staff; last verified 2026-11-10; owner platform-team

Chapters:
- 0:00 Why slots exist — /docs/video-slots-explained?t=0
- 0:12 Slots are hotel rooms — /docs/video-slots-explained?t=12
- 0:32 Holds: the booking — /docs/video-slots-explained?t=32
- 0:48 The catch: every room taken — /docs/video-slots-explained?t=48
- 0:59 Reserved slots — /docs/video-slots-explained?t=59
- 1:27 Requests on your behalf — /docs/video-slots-explained?t=87
- 1:42 The environment index — /docs/video-slots-explained?t=102
- 1:57 Recap — /docs/video-slots-explained?t=117

## Transcript

Imagine 10 engineers all building new features at the same time. Before anything reaches a customer, each change needs somewhere to be tried out. That somewhere is called a slot. Think of slots as hotel rooms for our software. Development and QA each have a small fixed number of them. Every room is already built with its own web address like QA-2. When an engineer pushes a change, a robot checks it into a free room automatically. But a room is only yours for a while. After your last push, you keep it for about four hours in development and 24 hours for a QA release. Push again and the clock restarts. Need longer? You can ask for up to a day in development or a week in QA. When time runs out, the room goes to someone else. That works until it doesn't. If every room is taken, a new deployment is turned away and the room you were using can be handed to someone else overnight. So here is the new idea, reserved slots. A reserved slot has a permanent name tag on the door. The tag can name a person, a specific branch or the automation robot. Unlike a normal booking, the tag never expires. Even when the hold runs out or the room is released, the tag stays. The system will never give that room to anyone else. If another engineer asked for it by number, the answer is no, along with the owner's name. It is smart about requests too. When someone asks for a deployment through the tech request portal, the robot acts on their behalf. So the request lands in their reserved room, not the robot's. And nobody can pretend to be someone else to grab a room. You can see all of this on the environment index, which room is held until when, which version it is running and who it is reserved for. Finished early? Release the hold with a tech request portal request and the room is free for the team. Slots are the rooms, holds are the bookings, and reserved slots are the name tags. Simple, fair, and predictable.