Platform & infrastructure

When a project exceeds its per-minute ingest limit, LoggerMan accepts the payload with 202 Accepted and enqueues it instead of dropping data. A background worker processes the queue every minute.

Dequeue order (highest priority first):

1. Scale — priority 3
2. Team — priority 2
3. Starter — priority 1

Within the same tier, requests are handled FIFO. Responses include tierPriority, position, and code: "QUEUED".

Ingest and read endpoints use an in-memory fixed-window limiter per server instance. On multi-instance deployments, limits apply per instance rather than globally.

API responses include X-RateLimit-Remaining and related headers on success and when queued.

• GET /api/health — liveness
• GET /api/health/ingest — ingest queue depth and status
• Public status page — human-readable SLA overview

Logs older than your plan retention window are purged on a scheduled job (every 6 hours). The dashboard stream already hides logs outside retention.

Dense INFO streams older than 7 days may be rolled into hourly summary logs when a bucket exceeds 25 events, reducing storage noise.

Deploy LoggerMan close to your users (e.g. Vercel regions). Point SDK baseUrl at that regional deployment. Edge routes (/api/projects/.../logs) accept ingest from Workers and edge runtimes via the slim SDK export.