Effective limits and quotas
Where HowlOps exposes the limits currently enforced for a workspace.
Read the current values
HowlOps stores capability plans and their limits in the platform catalog. The live catalog drives the pricing page, checkout, workspace usage, and server-side enforcement.
Use these sources instead of copying a quota table from documentation:
| Need | Source |
|---|---|
| Compare available plans and prices | Pricing |
| Inspect the public capability catalog | GET /api/v1/public/capability-plans |
| See the current workspace and change plans | Settings → Plan |
| See current consumption against limits | Settings → Usage |
The public catalog can add fields over time. Clients should ignore fields they do not recognise and use the capability and plan identifiers returned by the API.
Enforcement behavior
The effective limit is resolved for the authenticated workspace. It can control resource counts, minimum check intervals, retention, regions, notification methods, or status-page features.
When an operation exceeds a limit, the API rejects that operation with a structured error. It does not silently create a partially configured resource. After a scheduled downgrade or an ended trial, reconciliation can pause excess resources. Existing resources are preserved so they can be resumed after the workspace returns within its entitlement.
Rate limits
Rate limiting is applied by endpoint group and can differ between authentication, public reads, heartbeat pings, webhook ingestion, and authenticated product APIs. A 429 Too Many Requests response may include Retry-After and rate-limit headers. X-RateLimit-Reset, when present, is a delay in seconds.
Do not hardcode one global requests-per-minute value. Back off for the returned delay and retry only operations that are safe for your workflow. Selected billing mutations support an Idempotency-Key; it is not a universal API feature.
Inbound alerts
Every door alerts arrive through shares one budget per workspace: the Alertmanager webhook, the native Prometheus receiver, inbound webhooks and incoming integrations all count against the same number.
You can send at least 1,000 alerts a minute per workspace. The limit is counted per workspace, not per source address, so two workspaces sending from the same network never take budget from each other.
The stated figure is a floor rather than an exact maximum. In practice more gets through, because the count is kept by each API instance separately, and how much more depends on how your requests are distributed across them. Plan against the floor.
If you go over it, the request is answered with 429 Too Many Requests and:
| Header | Meaning |
|---|---|
Retry-After | Seconds to wait before sending again |
X-RateLimit-Limit | The limit currently in force |
X-RateLimit-Name | Which limit you hit — ingest_tenant for this one |
The response body repeats the same values as JSON, including window_seconds, so an automated sender does not have to parse headers. Wait for Retry-After and send again; alerts refused this way are not stored, so a sender that gives up loses them.
Ask support if you need a higher ceiling. It is a setting, not a rebuild, so it can be raised for your workspace without a release.
Was this page helpful?