Projects

Projects are the organizational layer between workspaces and checks. They group related checks together — typically by service, team, or environment — so you can manage and monitor them as a unit.

Why Use Projects

Without projects, all your checks live in a flat list. As your monitoring grows, it becomes hard to:

• Find the checks for a specific service
• Filter incidents to a particular team or component
• Scope deployments to the right set of checks
• Understand overall health at a glance

Projects solve this by grouping related checks under a shared container with its own health status.

Creating a Project

1. Navigate to Projects in the sidebar.
2. Click New Project.
3. Enter a name (e.g., "Backend API", "Payment Service", "Data Pipeline").
4. Optionally set the environment (production or staging).

Organizing Checks

Every check belongs to a project. When you create a check, you select which project it belongs to. You can also transfer checks between projects later if your organization changes.

A good rule of thumb: one project per deployable service. If two checks would be affected by the same deployment, they probably belong in the same project.

Example Organization

Project	Checks
Backend API	API health check, database backup, scheduled cleanup
Payment Service	Payment processor heartbeat, Stripe webhook monitor
Marketing Site	Homepage HTTP check, SSL certificate monitor
Data Pipeline	ETL hourly job, data sync cron, report generator

Project Health

Each project has an aggregated health status based on its checks. You can see at a glance whether all checks in a project are healthy or if any are down.

Deployments and Projects

Deployment windows are project-scoped. When you create a deployment, you associate it with a project. This lets you:

• Auto-pause all checks in the project during a release
• Scope the pause to specific checks within the project
• Track deployment history per project

Filtering by Project

Projects make it easy to focus on what matters. Throughout IonHour, you can filter by project:

• Checks list — View only checks in a specific project
• Incidents — Filter incidents to a project to focus on one service
• Deployments — See deployment history for a project

Best Practices

• One project per service. Group checks that would be affected by the same deployment. This makes deployment windows and incident filtering most useful.
• Use descriptive names. "Backend API" is better than "Project 1". Names should be instantly recognizable to any team member.
• Set the environment. Marking projects as production or staging helps you quickly identify which projects are customer-facing.
• Don't over-split. If two services are always deployed and monitored together, they can share a project. Too many projects adds overhead without value.
• Review project health regularly. The projects list gives you a quick snapshot of your entire monitoring setup. Make it part of your morning routine.