Limits and fair use

What Logu limits, what your agent sees when it reaches a limit, and what to do about it. Every number below is a constant in packages/protocol (FREE_PLAN_LIMITS, PLAN_QUOTAS, COST_CEILINGS, RATE_LIMITS); the full table of plans is in Plans and billing. Your own numbers and how much you have used are on Settings → Plan in the app (and in GET /v1/billing, for Owners).

There are three kinds of limit, and they fail differently:

A request that is refused is never created: an ask over a limit was not asked, no human saw it, and nobody answered it.

Plans#

Monthly counts are per calendar month in UTC and reset on the 1st. Pro is fair use: the quotas are a bound, not a target, and there is no overage billing yet. Free and Pro both keep history for 180 days. Plan quotas are shown in the app and counted from day one; they only start refusing requests when Logu turns enforcement on for everyone. Until then you only meet the rate limits and the ceilings.

Rate limits#

Per API key, per minute: 60 asks, 600 events and metric reports together, 120 image uploads, 1,200 requests of any kind (long-polls count). Per workspace, all its API keys and connectors together: 3,000 requests a minute; creating more keys does not raise it. Humans signed in to the app are not limited, except a few actions (a member can start at most 5 Checkout Sessions an hour, and send at most 5 delivery tests a minute). Sign-in and the device flow are limited per IP address.

The windows are aligned to the clock minute. A 429 carries Retry-After (seconds) and RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy. Wait that long and retry: the SDKs and the CLI do it for you.

Cost ceilings#

Every workspace has them, whatever its plan. You should not meet one; if you do, something is sending far more than a person would read.

Delivery channels never block an ask. The WhatsApp and email ceilings do not refuse a request: when one is reached, that channel skips the send and the ask still lands in the app and on every other delivery. Owners see a note on Settings → Plan.

What an agent sees at a limit#

Over a quota or a ceiling: 402#

{
  "error": {
    "code": "ceiling_reached",
    "message": "…",
    "hint": "Tell your human, don't assume their answer, and don't retry before the 1st (UTC).",
    "docUrl": "https://logu.dev/docs/errors#ceiling_reached",
    "requestId": "…"
  }
}

• plan_limit: the workspace is over a plan quota (asks, events or metric reports this month, image storage, projects, metric names; on Free also a third agent, inviting members and webhook endpoints). An Owner can upgrade to Pro in Settings → Plan; on Pro, ask for a higher quota.
• ceiling_reached: the workspace reached one of Logu's ceilings. Upgrading does not lift it.
• Neither is an answer. The SDKs raise PlanLimitError (TypeScript and Python), the MCP tools return a tool error that starts with plan_limit: or ceiling_reached:, and the CLI exits with a failure code (see logu help --json). An agent must not proceed as if a human had approved: tell your human and stop. Do not retry before the 1st (UTC): the count only resets then.
• The workspace's Owners are told once a month per meter (an event from Logu in the project logu and an entry in the activity log); with plan quotas enforced, also at 80% and at 100%.
• Images: only the upload is refused; sending the ask or event without the image works. Existing projects, metric names and API keys keep working when a limit on their number is reached.

Over a rate limit: 429#

Back off for Retry-After seconds and retry the same request (with the same Idempotency-Key for asks, so a retry never creates a second ask).

The long-poll#

GET /v1/asks/{id}/wait waits at most 50 seconds (maxWaitSeconds in GET /v1/me); an ask with no decision yet answers with the ask still waiting: call it again. That is not a limit being hit.

Fair use#

Logu is for agents that need a person: asks, events, metrics. Please do not:

• use it as a message broker, a log sink or a high-volume metrics pipeline (send a metric when its value matters to a person, not on every tick);
• create many workspaces, agents or accounts to get around a limit;
• send content you are not allowed to send, or use Logu to spam people (the email, WhatsApp and push deliveries reach real people);
• load-test the production service. Use a test API key for development, or run the API locally.

We may rate-limit, suspend or remove a workspace that puts the service or other customers at risk. We try to write to the Owners first when that is possible.

Test mode#

Test API keys (logu login --test, or an agent created with test: true) send asks, events and metrics that are shown in the app with a Test badge and are never delivered to anyone's phone. They have their own, smaller ceilings (above) and do not count against your plan quotas.

How to ask for more#

If you reach a quota on Pro, or a ceiling, or you have a use that is bigger than these numbers on purpose, write to the Logu team from the Owner's email with the workspace name, the meter, and what you are building. The team can raise a limit for one workspace; it takes effect on the next request.