Team Organization

This guide covers how to organize your Recuro teams for security, clarity, and operational efficiency.

Separate staging and production

Create separate teams for each environment:

• Production — Real workloads with real alerting
• Staging — Test schedules with relaxed alerting or alerts disabled

This gives you:

• Separate API tokens — No risk of accidentally creating production jobs from a staging script
• Separate usage limits — Staging does not consume your production quota
• Separate alerts — Staging failures do not trigger production alert channels
• Clean dashboards — Each environment shows only its own crons and jobs

Use least-privilege roles

Role	Give to
admin	Team leads, DevOps engineers, and anyone who needs to manage team settings, members, or billing
member	Developers who need to create and manage crons, queues, and jobs but should not modify team settings

Keep the number of admins small. Most team members only need member access.

One team per product or service

If your organization runs multiple products, consider creating a team per product:

Recuro Teams:
  ├── api-backend          → Crons for API health, data sync
  ├── payment-service      → Queues for webhook delivery, payment processing
  ├── marketing-site       → Crons for uptime monitoring
  └── staging              → Test crons and queues

This provides natural boundaries for alerting, billing, and access control.

Naming conventions

Use consistent naming across teams, crons, and queues:

• Teams: {product}-{environment} (e.g., api-production, api-staging)
• Crons: {purpose} ({frequency}) (e.g., “Health Check (5min)”, “Nightly Sync (2AM UTC)”)
• Queues: {service}-{action} (e.g., stripe-webhooks, email-notifications)

Next steps

• Managing Teams — Step-by-step guide
• Teams — Full concept reference