Available values are instance-specific. Treat the values displayed in Settings and returned by the Config API as authoritative for the current instance; do not copy limits from another environment.
Who should use this page
Use instance settings when you are preparing an environment for production, diagnosing a limit or retention issue, defining the default security posture, comparing environments, or collecting governance evidence before a release. Changing an instance setting affects a wider boundary than editing one Component, Job, or Endpoint. Review dependent workloads and make the change through an authorized administrator account.Open the settings surface
- Open the user menu and select Settings.
- Select an instance section in the left navigation.
- Compare current usage with the configured allowance or policy.
- Save editable configuration, then validate one representative workload.
Instance sections
Read limits correctly
Capacity
Capacity
A count or byte allowance such as Databases, Storage, Secrets, users, groups, or Endpoint definitions. The UI can pair the allowance with current usage.
Runtime boundary
Runtime boundary
A per-execution constraint such as a Job or Endpoint timeout. For currently documented execution products, configure up to 3,540 seconds and 4 GB where the instance exposes those controls.
Throughput
Throughput
A rate or accumulated execution allowance, for example Endpoint requests or Job execution time. Confirm the period shown by the current instance instead of assuming a calendar window.
Retention
Retention
A duration after which history, logs, artifacts, or other evidence can be removed. Retention is not an execution timeout and does not make a business record durable.
Feature policy
Feature policy
A boolean or configured behavior such as version history, scheduled webhook delivery, Agent memory, or a security rule.
Production configuration workflow
1
Record the effective baseline
Capture the instance ID, plan, relevant limits, current usage, retention windows, and security defaults. This establishes which values were in force for the release.
2
Map workloads to controls
Associate each Endpoint, Job, data store, integration, and Agent with the limits it consumes. Include retry behavior and worst-case payload sizes.
3
Set the governance policy
Configure IAM, retention, Agent security, and deployment defaults before increasing capacity. More quota does not compensate for an overly broad principal or missing lifecycle policy.
4
Validate representative paths
Exercise one synchronous Endpoint, one asynchronous Job, one data or Storage operation, and—when enabled—one Agent run. Inspect Traces, Jobs, and Activity for the same operation.
5
Review periodically
Revisit usage and retention after releases or traffic changes. Use alerts and operational reviews instead of waiting for a hard limit to interrupt production work.
Configuration by workload
Endpoints
Review request rate, execution-time consumption, timeout, total requests, and success rate together. A healthy average can hide a small set of slow or failing routes, so confirm the individual Endpoint in Traces and Observability.Jobs and automation
Job timeout, accumulated execution time, active Event and Schedule limits, Realtime capacity, and Webhook behavior describe different failure boundaries. Size long-running work as a Job, make side effects idempotent, and plan retries before increasing the timeout. See Jobs and Automation.Data and Storage
Database size, database audit capacity, Storage capacity, network transfer, and maximum single-file size are distinct controls. A file that fits the single-object limit can still exceed remaining storage or transfer allowance. Retention and file TTL are lifecycle policies described in Storage, not substitutes for capacity monitoring.Identity
User, group, role-group, service-identity, and API-key allowances govern different objects. Keep human and machine access separate, use least-privilege roles, and review membership even when capacity remains. See Identity and access.AI Agents
Agent settings provide global instructions, default plugins and routing guidance, a managed AI-response output ceiling, memory defaults, export/artifact retention, and instance security rules. Personal Assistant defaults remain account-specific, while each autonomous Agent has its own identity, service account, policy, memory scope, and workspace. See Assistant configuration and personalization for the complete layering model and Agent configuration for one Agent’s fields.API access
Administrators can retrieve effective instance configuration and usage through the Config operations in the Platform API reference. Use the API for inventory and governance automation, but keep credentials out of reports and source control.Failure and recovery
Release checklist
- Confirm the instance identity and environment before saving.
- Record the effective limits used by the release.
- Test just below and above important payload and timeout boundaries.
- Verify retention against contractual and audit requirements.
- Separate user, service-account, Endpoint, and Agent permissions.
- Correlate failures through Activity, Traces, logs, and Job history.
- Recheck capacity after rollout and after enabling retries or new schedules.
Limits and quotas
Understand execution and capacity boundaries.
Security and governance
Apply least privilege and retain evidence.
Observability
Verify the effect of configuration changes.