Projects & Organizations

Pulsimo uses a hierarchical multi-tenant architecture with Organizations containing Projects containing Endpoints.

Resource Hierarchy

Organization (Company)
  └─ Project (Environment/Team)
      └─ Endpoints (Services)
          └─ Health Checks
              └─ Incidents

An organization represents a company, team, or business entity. It's the top-level isolation boundary in Pulsimo.

Users in Org A cannot see data from Org B. Database-level isolation with organization_id ensures security.

Default check intervals, notification channels, branding, and feature flags at organization level.

Separate RBAC and permissions per organization with Owner, Admin, Member, and Viewer roles.

Usage tracking, endpoint limits, user limits, and retention policies per organization.

First Organization: Created automatically during registration. You become the Owner role with a default project created automatically.

Additional Organizations: Contact support for multi-org access. Each represents a separate billing entity with independent user base.

A project is a logical grouping of endpoints within an organization. Typically represents:

Production, Staging, Development, Testing

Backend, Frontend, Infrastructure, Data

E-commerce, CRM, Analytics, Payment System

For agencies managing multiple clients

Best practice example for organizing projects by environment:

Project	Alert Policy	Check Interval	Notification
Production	Strict (1 failure)	10 seconds	Slack + Email + PagerDuty
Staging	Moderate (3 failures)	30 seconds	Slack only
Development	Relaxed (5 failures)	60 seconds	Email summary only

📁 Organize by Environment: Create separate projects for Production, Staging, and Development with appropriate alert policies for each.

🎯 Clear Naming: Use descriptive project names like "production", "backend-staging", "frontend-dev" instead of "proj1" or "test".

🔐 Limit Access: Grant project-level permissions to restrict who can modify endpoints in sensitive environments like Production.