Skip to main content

Quotas and audit log

The web console provides two primary observability tools to ensure resource availability and enterprise security compliance: Quotas and the Audit Log. Both pages are read-only and accessible to all project members.

Quotas and capacity monitoring​

The Quotas view displays live resource consumption bars representing your project's allocated compute, memory, storage, and networking limits.

Quotas View

  1. In the left sidebar, navigate to Project → Quotas.
  2. Review real-time resource utilization bars for every capped resource category.
  3. Click Refresh at any time to query live usage metrics directly from the platform enforcement engine.

Interpreting capacity indicator bars​

Capacity progress bars use intuitive color-coding to warn you before hitting hard system caps:

  • Green (< 70% used): Healthy operating capacity. Sufficient overhead for scaling.
  • Amber (70% – 90% used): High usage threshold. Consider cleaning up stale workloads.
  • Red (> 90% used): Critical threshold. Deploying new agents or containers may fail due to quota exhaustion.
  • Unlimited Chip: Indicates that no artificial cap is placed on that specific metric for your project.

Metric definitions and default limits​

Every new project starts with standardized default resource allocations designed to accommodate multi-agent pipelines and containerized services:

Resource MetricConsole LabelWhat It LimitsDefault Allocation
Running InstancesRunning instancesTotal concurrently active agent, function, or container instances50 instances
ServicesServicesInternal network service objects held by your workloads100 services
Reserved CPUCPU (reserved)Total CPU processor cores guaranteed to running workloads10 cores
Reserved MemoryMemory (reserved)Total RAM guaranteed to running workloads20 GiB
Max CPU CeilingCPU (max)Maximum CPU burst threshold allowed across all workloads20 cores
Max Memory CeilingMemory (max)Maximum RAM burst threshold allowed across all workloads40 GiB

Those six are the whole default set. The Quotas page renders one bar per cap that is actually in force, so a project with the defaults shows exactly these six rows. The platform does not cap the number of workloads or persistent volumes today; if you have asked an operator for such a cap, it appears here as an extra row once it is set.

A service cap is not a workload cap

Services is generous because it counts infrastructure objects, not deployments. Each workload holds roughly four service objects at rest, and every retained non-active revision holds one more — six workloads were observed pinning 52 services after a night of redeploys. Exhausting this cap does not fail loudly: the next revision sits in "deploying" with a perfectly healthy container until revision garbage collection frees some. If you see that, check this bar before you debug the container.

Default Container Sizing

Workloads that do not explicitly define custom resource requirements receive a default runtime allocation of 100m CPU / 256Mi RAM reserved and 2 CPU / 4Gi RAM maximum ceiling. (100m represents 100 millicores or 0.1 CPU core; Gi represents gibibytes).

Requesting quota increases​

If your production workload requires higher capacity limits, contact your platform administrator or account manager. Quota increases are applied dynamically without requiring project downtime or service restarts.

Audit log and compliance tracking​

The Audit Log provides an immutable, append-only historical audit trail recording every state change, deployment, configuration edit, and credential access event within your project.

Audit Log View

Step-by-step audit inspection walkthrough:​

  1. Navigate to Security → Audit log.
  2. Review the chronological list of system actions, ordered with the newest events at the top.
  3. Inspect key fields for every recorded audit entry:
    • Time: Exact timestamp when the action occurred.
    • Actor: User email or service account ID responsible for the event. (System-generated actions show Platform System).
    • Action: Machine action identifier (e.g., agent.deploy, project.member.add, project.secret.reveal).
    • Target: Name or ID of the specific resource modified.
    • Detail: Contextual metadata, such as granted roles or configuration updates.

Filtering events and pagination​

The audit log uses cursor pagination to handle high-volume event histories efficiently without slowing down browser performance.

Step-by-step filtering workflow:​

  1. Filtering Loaded Rows: Use the Filter input box at the top of the log table to search currently loaded entries by user, action name, or resource ID.
  2. Paging Historical Entries: Scroll to the bottom of the audit table and click Load More. The console fetches the next historical batch of entries using a cursor token.
  3. Deep History Searches: To search events further back in time, click Load More repeatedly to pull earlier record batches before applying your text filter.

Audited action taxonomy​

Every operational change triggers an explicit audit log entry. Key action families include:

Functions audit as agent.*, not function.*

There is no function. action family. A function is deployed through the same route as an agent, so it records agent.deploy, agent.redeploy and agent.delete. The Filter box is a plain text match over the rows already loaded, so filtering on an action name that does not exist returns zero rows and looks exactly like "nothing happened".

1. Deployments and workloads​

  • agent.deploy / agent.redeploy / agent.delete — Agent and function lifecycle modifications.
  • agent.set-traffic — Splitting traffic across an agent's revisions.
  • agent.config / agent.file.write / agent.file.delete — Configuration and in-console source edits.
  • agent.embed.update / agent.embed.rotate-key / agent.embed.delete — Embedded chat widget changes.
  • serverless.service.create / serverless.service.update / serverless.service.set-traffic / serverless.service.delete — Container service lifecycle and routing.
  • serverless.trigger.create / serverless.trigger.update / serverless.trigger.delete — Trigger wiring on a service or function.

2. Access control and IAM​

  • project.create / project.rename / project.delete — Project lifecycle.
  • project.member.add / project.member.role / project.member.remove — Team membership updates.
  • project.member.sa.role / project.member.sa.remove — Service account membership on a project.
  • project.invite / project.invite.revoke / invitation.accept — Invitation lifecycle events.
  • project.break-glass — Platform administrator temporary emergency access events.

3. Credentials and secrets​

  • serviceaccount.create / serviceaccount.delete / serviceaccount.key.create / serviceaccount.key.revoke — Machine account management.
  • apikey.create / apikey.revoke — API key generation or revocation.
  • project.secret.write — Creating a secret and writing a new version of one. There is no separate create/update pair; a write is a write.
  • project.secret.delete — Removing a secret outright.
  • project.secret.bind / project.secret.unbind — Recording or removing a workload binding. Neither moves a value.
  • project.secret.apply — The action that actually reads bound values and writes them onto a workload. Each individual read is recorded as project.secret.reveal.
  • project.secret.reveal — Recorded whenever a plaintext value is read: by an admin in the console, and by Apply on the caller's behalf.
  • project.secret.issue-token — Minting a scoped, short-lived read token.

4. Cloud connection and inference​

  • project.crusoe-cloud.map / project.crusoe-cloud.unmap / project.crusoe-cloud.credential-check — Connecting, disconnecting, and re-checking the Crusoe Cloud credential.
  • project.crusoe-cloud.bucket.create / .bucket.delete / .repository.create / .repository.delete — Storage and registry provisioning in your own account.
  • project.inference.configure / project.inference.set / project.inference.mint / project.inference.delete — Managed Inference credential lifecycle.
Break-Glass Transparency

A platform administrator holds no authority over your project's resources — without a grant, their reads 404 exactly like a stranger's. To troubleshoot inside your project they must take a time-bound break-glass grant, which lands as an ordinary project membership and self-expires: 4 hours by default, 24 hours at most, after which they must take a fresh one with a fresh reason.

The reason is required, not defaulted — a request with fewer than 8 characters is refused — and it is shown to your project's members verbatim. A live grant raises a banner at the top of Project → IAM & members naming who holds what access, until when, and their stated reason, and the member's own row is badged platform support rather than rendering as an ordinary colleague. It is logged as project.break-glass with the reason, the role taken, and the expiry.

Next steps​