Cursor Rules Template: Status Page SaaS with Incidents, Subscribers, Uptime Monitors, and Team Notifications

Overview

Direct answer: This Cursor rules template configures a Node.js Express based Status Page SaaS for incidents, subscribers, uptime monitors, and team notifications. Paste the following .cursorrules block into your project root to enforce architecture, security, testing, and CI practices for Cursor AI assisted development.

The Cursor rules template is tailored for a modern SaaS stack that surfaces incident status, monitors uptime, subscribes users to updates, and routes team notifications across channels. It emphasizes a clean directory structure, explicit auth, and observable behavior that supports reliable uptime reporting and incident response.

When to Use These Cursor Rules

• Starting a new Status Page SaaS with incident and uptime data needs a repeatable, guarded configuration.
• You want enforceable project structure, testable endpoints, and secure RBAC for incidents and subscribers.
• You require consistent CI pipelines, linting, and migrations for PostgreSQL schema changes.
• You need reliable team notifications via configured channels when incidents occur.

Copyable .cursorrules Configuration

Framework Role & Context:
You are Cursor AI configured to help build a Node.js Express based Status Page SaaS with incidents, subscribers, uptime monitors and team notifications. Provide production-ready structure and guardrails.

Code Style & Style Guides:
Use ESLint and Prettier with TypeScript where possible. Enforce strong typing and explicit error handling.

Architecture & Directory Rules:
Root: /project
Dirs: /src, /tests, /config, /migrations
src/controllers, src/routes, src/models, src/services, src/repositories, src/middleware, src/db
Separate migration scripts in /db/migrations

Authentication & Security Rules:
JWT-based auth for API endpoints; avoid leaking secrets; RBAC for incidents and subscribers; TLS enforced in transport; rotate keys.

Database and ORM patterns:
PostgreSQL as the database; use a safe ORM compatible with your stack and TS types; parameterized queries; migrations for schema changes.

Testing & Linting Workflows:
Unit tests with Jest; integration tests for routes and DB; CI runs tests and lint; include type checks.

Prohibited Actions and Anti-patterns for the AI:
Do not embed secrets in code; do not bypass auth; do not write to global state; avoid synchronous DB calls; do not create monolithic handlers; no vendor lock-in.

Recommended Project Structure

src/
  api/
    v1/
      incidents.ts
      subscribers.ts
      uptimeMonitors.ts
      notifications.ts
  controllers/
  models/
  repositories/
  routes/
  services/
  middleware/
  db/
    migrations/
tests/
config/
migrations/

Core Engineering Principles

• Security-first design with RBAC and least privilege
• Clear API contracts and data validation
• Observability through structured logs and metrics
• Idempotent operations for webhooks and updates
• Test-driven approach with unit and integration tests
• Good separation of concerns and maintainable code structure

Code Construction Rules

• Endpoints must be small and purpose-specific; avoid fat controllers
• Use repository layer for data access; avoid raw queries in business logic
• Schema migrations are required for any DB changes
• Use parameterized queries and ORM safety features
• Validate inputs at boundary; return consistent error shapes
• Document API responses and status codes in code comments

Security and Production Rules

• Use TLS, rotate secrets, and store them in env vars
• JWT tokens with short lifetimes and refresh flows
• Back-pressure and rate limiting to protect endpoints
• Audit trails for incidents and subscriber changes
• Environment based config and feature flags for safe rollouts

Testing Checklist

• Unit tests for controllers and services
• Integration tests for API routes and DB access
• End-to-end tests for incident creation, alerting, and subscriber updates
• Lint and type checks in CI; run migrations in test env

Common Mistakes to Avoid

• Skipping input validation or unsafe casts
• Relying on in-memory state for critical data like incidents or uptime data
• Neglecting RBAC and audit logging
• Ignoring migrations or letting schema drift
• Revealing secrets via logs or error messages

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

• Cursor Rules Template: SaaS Revenue Dashboard (MRR, ARR, Churn & Cohorts)
• Cursor Rules Template: Python FastAPI API Monitoring
• Cursor Rules Template: Cash Flow SaaS with Bank Imports, Invoices, and AI Predictions
• Cursor Rules Template: Rental Marketplace with Property Listings, Applications, Tenant Screening, Payments and Messaging

FAQ

What is the Cursor Rules Template for a Status Page SaaS?

The Cursor Rules Template provides a copyable .cursorrules block and guardrails to build a Node.js Express based Status Page SaaS with incidents, subscribers, uptime monitors and team notifications, including architecture, security and testing guidance.

Which stack does this template target?

It targets a Node.js with Express and PostgreSQL backend, using JWT based authentication and a modular API architecture for incidents, subscribers, uptime monitors and team notifications.

How do I apply the .cursorrules block?

Save the content inside the Copyable CursorRules Configuration block to a file named .cursorrules at your project root, then adapt env vars and models for your environment.

Can I adapt this to other stacks?

Yes, the guardrails and structure are designed to be adapted; you can switch ORM, language features, and tooling while preserving security, testing, and deployment guidance.

What security practices are included?

Environment variable secrets, RBAC, transport TLS, rotated JWT secrets, and audit trails for incidents and subscriber data.