Projects
Group related checks and jobs into projects so you can monitor, filter, and manage each service on its own.
Projects are how you organize monitoring inside a workspace. Instead of one long list of checks and jobs, you group the ones that belong to the same service, team, or environment — for example a "Backend API" project and a separate "Data Pipeline" project.
Every check, job, and dependency lives inside a project. Projects give you a health rollup for that group, a scoped view for filtering, and a boundary for things like deployment windows and status page components.
The Project Picker
When you're in the Monitoring, Incidents, or Explore areas of the app, a project picker appears near the top of the sidebar, just below the workspace switcher. It shows the name of whichever project you currently have selected, or All projects if none is selected.
Click it to:
- Switch projects — everything on screen (checks, incidents, dashboard stats) narrows to that project.
- Select "All projects" — clears the filter and shows everything in the workspace again.
- Jump to the full projects list — click the folder icon next to the picker.
Your selection is remembered as you move between pages, so you don't have to re-select a project every time you switch screens. It's also remembered per workspace: switching to a workspace shows the project you last had selected there, or "All projects" if you've never selected one in that workspace before.
The Projects List
Open Projects from the folder icon next to the picker (or navigate there directly) to see every project in the workspace, with its environment, check count, health, and creation date.
For each project you can see:
- Name and description — the project's label and an optional one-line summary.
- Environment — an optional Production or Staging tag.
- Checks — how many checks currently belong to the project.
- Health — Healthy, Impacted, or Down, rolled up from the status of every check in the project. Projects with no checks yet show No checks instead.
- Created — how long ago the project was set up.
Use the search box to filter by name or description, and click any column header to sort. Clicking a row opens that project (equivalent to selecting it in the project picker) and takes you to the dashboard.
Creating a Project
Open the create form
Click New Project from the projects list. The project picker dropdown only lets you switch between existing projects — you'll always start a new project from the list.
Name it
Give it a name — at least 2 characters. This name shows up in incident notifications and on your status page, so make it something your whole team recognizes at a glance.
Add an optional description
A short, one-line note (up to 140 characters) about what the project covers.
Choose an environment (optional)
Mark it as Production or Staging to help you tell customer-facing projects apart from internal ones when filtering.
Create
Click Create project. You're switched into the new project immediately so you can start adding checks.
Every plan has a limit on how many projects you can create. If you're at your limit, Ionhour blocks the create form and points you to upgrade instead.
Project Settings
Click Settings from a project's row menu (or the picker) to open its settings page. This is also where you manage the project itself, separate from the checks inside it.
General — edit the project's name, description, and environment, and view its Project ID (useful if you're scripting against the API).
Overview — a snapshot of the project's current state: total checks, down checks, impacted checks, uptime percentage, and alerts triggered, plus when it was created and last updated.
Danger Zone — two destructive actions, each requiring you to type the project's name to confirm:
- Transfer Project — move the project, and every check inside it, to a different workspace you belong to. This also removes its escalation policies, clears any status page component references, and detaches dependency links, since those are specific to the original workspace.
- Delete Project — permanently remove the project along with all of its checks, jobs, incidents, and signal history. This cannot be undone.
Managing Projects from the List
The row menu on the projects list (the ⋯ button) gives you quick access to the same actions without opening the settings page:
- Settings — jump to the project's settings page.
- Duplicate — create a new project with the same name (suffixed "(Copy)"), description, and environment. This copies the project's settings only — checks are not duplicated, so you'll add fresh ones to the new project.
- Transfer — same as the Danger Zone transfer, available inline.
- Delete — same as the Danger Zone delete, available inline.
Deleting is permanent
Deleting a project removes every check, job, incident, and signal inside it immediately. There's no undo from the UI — make sure you mean it before you type the confirmation name.
Best Practices
- One project per deployable service. If two checks would be affected by the same release, they probably belong together.
- Use descriptive names. "Backend API" tells your team more than "Project 1," and it's what shows up in incident alerts.
- Set the environment. Tagging a project Production or Staging makes it easy to spot which ones are customer-facing.
- Don't over-split. Services that always deploy and get monitored together can share a project — too many thin projects just adds overhead.
Next Steps
Checks
Create and manage the checks that live inside your projects.
Dependencies
Link checks together so failures propagate correctly across a project.
Workspace Settings
Manage settings that apply across every project in your workspace.
Switching Workspaces
Move between the different workspaces you belong to.