Service and runbook limits

Each project's response catalog has two independent limits:

Entry type	Maximum live entries per project
Services	500
Runbooks	500

A service does not consume a runbook slot, and another project has its own limits. Deleted entries do not count toward the live-entry limits. Older revisions of a runbook are not additional live runbooks.

Creating entries concurrently

The limits apply to concurrent requests as well as sequential ones. With 499 live runbooks and no other changes, eight valid requests to create runbooks with distinct unused keys can create only one additional runbook. The remaining requests are refused with HTTP 429 and a message beginning with CATALOG_LIMIT. The same rule applies independently to services.

A capacity refusal does not create an entry or reserve its key. Capacity depends on live entries, so waiting or sending more requests in parallel does not create additional capacity. Ask your agent to remove an unused live entry, wait for that deletion to complete, then retry the refused request. Over MCP the removal is delete_response_service or delete_runbook; in the CLI it is anectico service-catalog delete or anectico runbooks delete. Read the current entries first with list_response_services and list_runbooks (CLI: anectico service-catalog list and anectico runbooks list). A runbook used as a live service's default cannot be deleted until you remove that reference.

Pending service creation

A service awaiting confirmation of its alert binding already occupies a live-service slot. Retrying the identical pending creation can complete that existing service even when the project is at capacity; it does not create a second service or use another slot. A different new service still needs free capacity.

Changes to existing entries do not require an additional catalog slot. Use the current revision when editing or deleting an entry, as described in the incident and on-call guide.