> For the complete documentation index, see [llms.txt](https://docs.statuspal.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.statuspal.io/next/status-pages/services-and-containers.md).
# Services and containers
Model what your customers see on the status page: the services you report on, the containers that scope them to a region or environment, and how their status and uptime are shown.
Services are the components your status page reports on, and containers scope them to a region, environment, or product line. Together they define the grid visitors see, the components subscribers can follow, and the source of your page's overall status and uptime history.
{% hint style="info" %}
**Status page services are not incident management services.** These services appear on a status page and belong to that page. The services under **Incident Management → Services** are internal and organization-wide. The two connect only through [status page mapping](/next/incident-management/configure-incident-management-services.md#status-page-mapping).
{% endhint %}
## Containers
A container is a named column on your status page, such as **US**, **EU**, or **Production**. Use containers when the same service runs in several places and can fail in one without failing in the others. A visitor in Europe wants to know whether the API is down in the EU, not whether it is down somewhere.
Manage them from your status page's **Settings → Containers**. This area is admin only. Each container has a **Name**, a **Slug** used in URLs and the API, and a set of **Services**. A container must hold at least one service, and picking a service that is currently global scopes it to containers. Deleting a container is safe for its services: any service that lived only there becomes global again. Such a service also leaves its [service group](#service-groups), unless the whole group lived only in that container, in which case the group becomes global along with it.
If your services do not vary by region or environment, skip containers entirely. Every service is then global and the page shows a simple list.
## Services
A service is a single component, for example **API**, **Website**, or **Background jobs**. Each carries a live status that visitors see and subscribers can follow. Add and edit them from your status page's **Settings → Services**, also admin only.
There are two kinds:
* **Global services** apply everywhere and have one status. They are listed on their own below the container grid.
* **Container services** are available in some or all of your containers and carry a separate status in each. Background jobs in the screenshot runs in Asia and US but not in the EU, so the EU column stays empty for it on the status page.
The service form asks for a **Name**, an optional **Slug** (generated from the name if left blank), the **Type**, and for container services the containers it is **Available in**. A service that is the only one in a container cannot be removed from it; delete the container first.
Services appear in the same order everywhere, in the grid and in the global list, so put the ones customers care about most at the top.
## Service groups
A service group is a named heading that clusters related services together, such as **IT Services** holding **Support** and **Helpdesk**. Groups are about presentation: they make a page with dozens of services scannable, in the admin console and for visitors.
Groups are independent of containers. A service can be scoped to containers and belong to a group at the same time; the two answer different questions. A container says *where* a service runs, a group says *what it sits alongside*.
Groups also head the service badges on a notice, so an incident touching several services in one group reads as that group rather than as a run of unrelated names. See [Post updates and manage service impact](/next/status-pages/incident-maintenance-and-info-notices.md#post-updates-and-manage-service-impact).
Groups live in the Services Settings page itself, not on a form of their own. Click **New Group** above the **Container services** grid or the **Global services** list and a heading appears at the bottom of that section, ready to be named. Drag services onto it to fill it. A group needs only a **Name**, unique on the page.
A group may sit empty, and it stays in the section you created it in. The Services Settings page marks it with a **Drop services here or delete the service group** warning, because an empty group appears nowhere else: not on the public status page, not in the operational dashboard, and not in the notice or subscribe forms. Removing the last service from a group empties it rather than being refused — use **Delete group** when you want it gone.
Rename a group by typing over its heading, or pick **Rename** from the **⋮** menu on its row to jump straight into it. **Delete group** from the same menu removes the heading — its services stay exactly as they were, just ungrouped. Like everything else on this page, new groups, renames and deletions only take effect when you click **Save services**.
{% hint style="info" %}
**A group holds one type of service only.** Every service in a group is either global or container-scoped, never a mix. Changing a service's type removes it from its group, and the **Group** dropdown on the service form only offers groups that match the type you have selected.
{% endhint %}
To move a whole group between types, drag its heading from one section to the other — the members travel with it and are all re-scoped at once, so the group stays intact. Dragging a single service across instead takes that one service out of its group. The same move is available over the API: `PATCH /service_groups/{slug}` with a `containers` list.
Dropping a group's heading **inside** another group merges the two: the services it brought join the group it landed in, and the heading you dragged is removed. An empty group has nothing to merge, so it can only be dropped between groups. The member counts update while you drag, so you can see the result before you let go — and, like everything else here, nothing is saved until you click **Save services**.
Wherever services are listed, grouped ones appear under their group heading and ungrouped ones appear as ordinary rows: the Services Settings page, the incident, maintenance and info forms, the operational dashboard, the subscribe forms, and the public status page. Click a group heading to collapse or expand it. On the operational dashboard and the public status page, every group heading also carries a **rollup status**, the worst status among its members right now, shown per container in the grid and once for a global group. In the incident and maintenance forms the heading shows the worst status that notice gives its members instead, follows your choices as you change them, and stays blank while the notice affects none of them. A group has no status of its own; it is always computed from whoever currently belongs to it, so it updates the moment a member changes.
## Organize and reorder services
The Services Settings page is a working surface, not just a list. Drag a row by its handle to reorder services. Drag a row between the **Container services** grid and the **Global services** list to change its type. Drop a row directly under a group heading to put it in that group, or above the first heading to leave it ungrouped. Group headings drag too, and carry their services with them. To place a service *after* a group without joining it, drop it on the **Drop here to leave…** strip that appears below the group while you drag. Flip the toggles in the grid to add or remove a service from a container. Nothing is saved until you click **Save services**, and **Cancel** discards everything.
{% hint style="warning" %}
**Changing scope can disconnect automation.** Monitoring checks and incoming webhook automations target a specific service in a specific container. If you remove that container from the service, or turn a container service global, those links are lost. StatusPal Next warns you before saving when this would happen, so read the confirmation before you accept it.
{% endhint %}
## Change service status manually
Day to day, statuses change through [notices](/next/status-pages/incident-maintenance-and-info-notices.md), [monitoring checks](/next/monitoring/connect-checks-to-status-pages.md), [incoming webhooks](/next/status-pages/automate-status-updates.md), and published [incidents](/next/incident-management/manage-incidents.md). When you need to set one by hand, open your status page in the sidebar and choose **Services**. Both members and admins can use this page.
Click the status icon for a service in a container, or for a global service, and pick **Operational**, **Degraded**, **Partial outage**, **Unavailable**, or **Under maintenance**. Change as many as you need, then click **Update status** to save them all at once.
A manual change updates the status page immediately and fires your outgoing webhooks. It does not create a notice and does not notify subscribers. Use it to correct a stale status or reflect something you are not going to write up. If your audience should hear about it, report an incident or schedule maintenance instead, and let the notice set the status.
A small code icon on a status marks a component that an incoming webhook automation drives. You can still change it by hand, but the next webhook call will overwrite you.
## Understand overall status and uptime history
The banner at the top of your status page summarises everything below it. It reads **All services are operational** when every component is Operational, and otherwise names the worst state: **Some services are degraded**, **Some services are partially unavailable**, or **Some services are unavailable**. While a maintenance is in progress and no incident is open, it reads **Maintenance in progress**. An open incident notice that names no affected services shows **There is an ongoing incident.**
The banner is computed, not set. It follows the worst status across all components on the page, with any ongoing incident notice taking precedence, so the only way to change it is to change a service status or resolve the notice.
Below the services, the **uptime graph** shows one cell per day over the configured period, with the overall uptime percentage for that period in the corner. There is one graph per status page. Each day is coloured by the worst incident that touched it: yellow for Degraded, orange for Partial outage, red for Unavailable, and green for a clean day. Hover a day to see its date, its uptime, and the notices that ran that day. The graph refreshes every few minutes.
Uptime counts time spent in an incident notice at Partial outage or Unavailable as downtime. Degraded incidents colour the day but do not reduce the percentage, and maintenance never counts as downtime. Only notices affect the graph; a status you set by hand on the Services page does not.
You can hide the graph or change its period under **Settings → Customization**, covered in [Customize your page](/next/status-pages/customize-your-page.md).
