Skip to main content

Quotas and audit log

This page explains the two read-only pages every project gets: Quotas, which shows how much of your capacity limits you are using right now, and the Audit log, which shows who changed what.

The Quotas page​

Project → Quotas shows one bar per capped resource. A quota is a per-project limit on running capacity, enforced by the cluster itself — the numbers are read live from the same mechanism that does the enforcing, so what you see is what is actually enforced.

Each bar shows the used amount, the limit, and a percentage, for example:

Running instances: 3 / 50 (6%)

Reading the bars​

  • Green — under 70% used.
  • Amber — 70% to 90% used.
  • Red — over 90% used. New deployments may start failing when a limit is hit.
  • "Unlimited" chip — a limit of 0 means that resource has no cap.

The Refresh button re-reads live usage on demand.

What the labels mean​

Label on the pageWhat it limits
Running instancesTotal running pods (each instance of an agent, function, or service)
ServicesNetwork services
CPU (reserved)CPU reserved by all workloads combined
Memory (reserved)Memory reserved by all workloads combined
CPU (max)The ceiling any combination of workloads can burst to
Memory (max)The memory ceiling
WorkloadsDeployed workload objects
Storage volumesPersistent storage volumes

Default limits​

Every new project starts with:

ResourceDefault
Running instances50
Services30
CPU (reserved)10
Memory (reserved)20Gi
CPU (max)20
Memory (max)40Gi

Containers that don't declare their own sizing get a default limit of 2 CPU / 4Gi and a default reservation of 100m CPU / 256Mi memory.

Raising a limit

Honest alpha note: the Quotas page is read-only, and there is no API endpoint to raise a cap yet. If you are hitting a limit, contact the team operating your platform.

See platform limits for every limit in one place.

The Audit log page​

Security → Audit log is the project's append-only change history: every state change, newest first, readable by any project member — not just admins. Transparency is the point: the log includes actions taken by the platform provider itself, such as break-glass grants.

Each entry shows:

FieldMeaning
TimeWhen it happened
ActorWho did it — the email of the user or service account. Empty means the platform system itself.
ActionA dotted machine name like agent.deploy — the console adds a plain-English gloss next to it
TargetWhat it happened to
DetailExtra context, such as the role that was granted

Filter and load more​

The page loads a batch of entries and a Load more button fetches the next batch (the log can be long; it pages on a cursor). The filter box narrows what is shown — note that it filters the rows already loaded, not the whole history. To search further back, keep clicking Load more, then filter.

What actions appear​

Everything that changes state gets recorded. The families you will see most:

  • Deployments and workloads — agent.deploy, agent.redeploy, agent.delete, agent.config, file writes, traffic changes. (Functions ride the agent pipeline, so a function deploy appears as agent.deploy.)
  • Membership and access — project.member.add, project.member.role, project.member.remove, project.invite, project.invite.revoke, invitation.accept, and — loudest of all — project.break-glass.
  • Credentials — serviceaccount.create, serviceaccount.key.create, serviceaccount.key.revoke, apikey.create, apikey.revoke.
  • Secrets — writes, deletes, bindings, and every project.secret.reveal (reading a secret's value is itself an audited event).
  • MCP servers — creates, tool publishes, version rollbacks and yanks.

The complete action list, and what the log does and does not guarantee, is in break-glass and audit.

Alpha limitations

The audit log currently has no export, no retention controls, and no server-side date-range query — you page backward with Load more. These are known alpha gaps, not design choices.

Next steps​