---
title: "Agent OS Troubleshooting Guides"
description: "Discover answers to common troubleshooting questions about Agent OS."
url: "https://www.contentstack.com/docs/agent-os-troubleshooting/faqs"
product: "Contentstack"
doc_type: "guide"
audience:
  - developers
  - admins
version: "current"
last_updated: "2026-08-05"
---

# Agent OS Troubleshooting Guides

## Workspaces, Access & Administration

### Agent OS Projects Not Visible Due to Organization Role Constraints

A user may have stack access but cannot see or access Automation Hub projects, preventing them from viewing or managing automations.

**Root Cause**  
Automation Hub access is governed at the organization level; Member roles may not have required privileges.

**Resolution**

1.  Navigate to the automation project's **Settings tab**.
    
2.  Under the Members or Invitations section, **invite the individual user** to the project.
    
3.  Log out and log back in to refresh their session if the project does not appear immediately.
    

Users can view Automation Hub projects and open/create automations.

### Recovery Options for Deleted Automations / Backup Expectations

Customers may ask how to recover deleted automations and whether configuration backups exist.

**Root Cause**  
Deleted automation configurations are not recoverable from within the UI; restoration is not supported unless disaster recovery is involved.

**Resolution**

1.  Confirm automation deletion scope (which project, when deleted).
    
2.  Recommend rebuilding from documentation/export (if export exists).
    
3.  If business-critical, initiate DR requests through the internal database team (process-dependent).
    
4.  Recommend governance controls:
    
    *   Export automations periodically
        
    *   Maintain versioned configuration repo
        

Automation is recreated successfully (or restored via approved DR process).

### JSON Import Fails Because Connectors/Tokens Do Not Exist in Target Org

When importing automation JSON into another organization, the import may fail or result in incomplete configuration because referenced connectors/tokens are missing.

**Root Cause**  
JSON imports do not resolve dependencies (connectors, auth tokens) across orgs.

**Resolution**

1.  Confirm which connectors and tokens are referenced in the JSON.
    
2.  Recreate required connectors in target org (if permitted).
    
3.  Prefer recipe-link import for cross-org migration when available.
    
4.  After import, rebind connections and validate action authentication.
    

  
Automation imports with all steps configured and actions authenticate successfully in the target org.

### “Provided Access Token Has Insufficient Scopes” During Automation Setup

During automation setup (especially stack selection), UI may display a token scope error preventing configuration.

**Root Cause**  
Session/cache behavior leading to stale authorization context.

**Resolution**

1.  Clear browser cache and cookies for the domain.
    
2.  Log out and log back in.
    
3.  Retry the stack selection step.
    
4.  If it persists, test in incognito or alternate browser.
    

  
Stack selection succeeds and the automation can be saved and executed.

### Automation Limit Inquiry With Insufficient Details

The customer asks about automation limits but does not provide enough technical or subscription context to assess the constraint.

**Root Cause**  
Missing required details (subscription, observed error, affected automation counts, runtime metrics).

**Resolution**  
Request:

*   Plan/subscription context
    
*   Automation project and workflow name
    
*   Error message(s)
    
*   Run History timestamps
    
*   Any limit UI message or API response
    

  
Sufficient information is collected to provide a limited explanation or remediation path.

### Transfer Ownership of an Automation Project

Customer requests to transfer Automation project ownership to another user for governance or access continuity.

**Root Cause**  
Direct ownership transfer is not supported.

**Resolution**

1.  Export automations from the existing project (requires org admin).
    
2.  Create a new Automation project under the target owner account.
    
3.  Import the exported automation(s) into the new project.
    
4.  Validate connections and credentials.
    

  
Automation runs under the new project and is administered by the intended owner.

### OAuth Configuration, Authorization Warnings, and Impact of User Deactivation

Customers may see OAuth authorization warnings, have uncertainty about org selection during OAuth, or observe automation failures when the creating user is deactivated.

**Root Cause**

*   OAuth authorization is org-specific and depends on selection during consent.
    
*   Revoking an authorization invalidates tokens used by dependent automations.
    
*   Automations can fail if created under a user who is later deactivated (token/user-context dependency).
    

**Resolution**

1.  Re-authorize OAuth ensuring the correct org is selected.
    
2.  Avoid revoking active OAuth authorizations used by production automations.
    
3.  Migrate critical automations to approved service accounts before deactivating users.
    

  
Automations continue running successfully after OAuth validation and user lifecycle changes.

### Contentstack MCP Tool Fails to Validate Parameters in VS Code

When using the Contentstack MCP tool in VS Code, tool calls fail with a parameter validation error, and the tool cannot fetch entries or content models as expected.

**Root Cause**

The error stems from how environment variables are handled when the MCP tool is configured through the VS Code extension, rather than through a dedicated per-stack configuration file.

**Resolution**

1.  Create a custom mcp.json configuration file inside your project’s .vscode folder to define stack-specific environment variables explicitly, instead of relying on global environment variable handling.
    
2.  Uninstall the MCP extension through the VS Code UI.
    
3.  Reinstall the MCP extension through the VS Code UI.
    
4.  Reload the VS Code window.
    
5.  Retry the operation that previously failed (for example, fetching entries or content models) to confirm the parameter validation error is gone.
    

The MCP tool fetches entries and content models as expected, with no parameter validation errors.

### Agent OS Page Is Blank, Missing from the App Menu, or Not Showing Execution Log

The Agent OS section is unreliable in the browser: the Automations page fails to load, Agent OS does not appear in the app menu at all, or the execution log list appears empty even though automations are running.

**Root Cause**

These symptoms most often trace back to one of two causes: browser-side caching, cookies, or extension interference in your normal browser profile; or, for the app-menu case specifically, an account role below Org Admin, Agent OS typically requires Organization-level Admin access, and a Member-level role may not see it at all.

**Resolution**

1.  Open Agent OS in an incognito/private browser window to rule out cache, cookies, or extension interference from your normal profile.
    
2.  If Agent OS loads correctly in incognito but not in your normal profile, clear your browser cache and cookies, or try a different browser.
    
3.  If the page still does not load, update your browser to the latest version and perform a hard refresh.
    
4.  If Agent OS is missing from the app menu specifically (not just failing to load), confirm your role at the organization level. Member-level access may not be sufficient, and Organization Admin (or equivalent) access is generally required.
    
5.  If the execution log appears empty, clear your browser cache first, since this alone has resolved missing-log cases previously.
    
6.  If clearing cache, using incognito, and trying different browsers do not resolve missing execution logs, and you see a 403 Forbidden error in your browser’s network tab, this points to a different, unresolved issue rather than a simple caching problem, contact Contentstack Support directly with a HAR file rather than continuing to try browser-level fixes.
    

Agent OS loads normally in your regular browser profile, appears in the app menu for users with the required Org Admin access, and execution logs display as expected. If the 403/network-level pattern applies instead, escalate to Support rather than expecting cache-clearing to resolve it.

## Triggers, Filters & Workflow Logic

### Automation Entry Trigger Returns Unexpected Entry Payload During Test Runs

When validating an Entry-based trigger in Automation Hub using “Test trigger” or a controlled entry update, the trigger payload may intermittently differ from the expected entry response (for example, returning an older snapshot of the entry or a mismatched entry object). This can impact downstream mapping and create uncertainty during workflow validation.

**Root Cause**  
Creating a new trigger and retesting produced correct and consistent payloads, indicating the behavior was likely transient or tied to trigger state/config caching at the time of testing.

**Resolution**

1.  In Automation Hub, open the affected automation and document the trigger configuration (content type, environment, branch, and filters).
    
2.  Create a **new entry trigger** with the same intended configuration.
    
3.  Reconnect downstream actions (or clone the automation and swap the trigger).
    
4.  Run controlled tests:
    
    *   Update a single known entry (e.g., change a text field).
        
    *   Confirm the trigger payload reflects the updated entry values.
        
5.  If the problem recurs, collect:
    
    *   Trigger configuration screenshot
        
    *   Entry UID and content type UID
        
    *   Time of test run
        
    *   Run History payload snapshot
        

  
In Run History, the trigger payload consistently matches the updated entry and the expected content type/UID across repeated tests.

### Automation Not Executing Because Trigger Filter Logic Does Not Match Event

An automation may not execute even though the entry event occurs (create/update/publish), causing expected actions (webhooks, updates, notifications) to never run.

**Root Cause**  
A trigger filter condition was configured such that the event did not satisfy the filter expression (for example, mismatch in field value check, incorrect operator, or missing field path).

**Resolution**

1.  Open the automation → Trigger configuration.
    
2.  Review all filter conditions:
    
    *   Confirm field path is correct
        
    *   Confirm operator is correct (equals, contains, exists, etc.)
        
    *   Confirm expected value casing and format
        
3.  Temporarily simplify the filter to a minimal condition to validate execution.
    
4.  Reintroduce conditions incrementally to isolate the blocking condition.
    
5.  Retest by generating the same event using a controlled entry update/publish.
    

  
Automation is triggered consistently for matching entry events and does not trigger for non-matching events.

### Trigger AND/OR Conditions Do Not Behave as Expected

Teams may observe unexpected trigger firing patterns when using compound AND/OR conditions, causing workflows to execute too broadly or not at all.

**Root Cause**  
Logical grouping/precedence misunderstanding (configuration design) rather than platform malfunction.

**Resolution**

1.  Document expected logic in plain language.
    
2.  Rebuild conditions using explicit grouping and reduced complexity.
    
3.  Test with known cases:
    
    *   Case that should trigger
        
    *   Case that should not trigger
        
4.  Introduce conditions incrementally to isolate behavior.
    

  
Trigger firing aligns with expected truth-table logic across test cases.

### Automation Not Triggering After Switching a Trigger to a Cron Schedule

After changing an automation’s trigger to a Cron schedule and setting a timezone, the automation stops firing on its expected schedule and no execution log are generated, even though the automation remains enabled.

**Root Cause**

Contentstack’s “Etc” timezone identifiers use reversed sign conventions compared to standard UTC notation. For example, Etc/GMT-5 actually represents UTC+5, not UTC-5 as the name might suggest. Configuring the Cron trigger with the wrong sign in mind causes the automation to run at an unexpected time relative to what you intended.

**Resolution**

1.  Open the Cron trigger configuration for the affected automation and check which “Etc” timezone identifier is set.
    
2.  Remember that “Etc” timezone names use reversed signs relative to UTC - Etc/GMT-5 means UTC+5, and Etc/GMT+5 means UTC-5.
    
3.  Recalculate the Cron expression and timezone combination based on the correct UTC offset for your intended trigger time.
    
4.  Update the timezone configuration accordingly and save the trigger.
    
5.  Monitor the Execution Log to confirm the automation now fires at the expected schedule.
    

The automation runs on the intended schedule, and execution log are generated for each scheduled run.

### Entries Show Different Publish Status Depending on Which Environment or View You Check

An automation that ingests data from Contentstack appears to be pulling entries that show as “not published” on the entry page, while the entries list view shows some of those same entries as “Published” with a “Schedule Publish Failed” flag, creating confusion about the entries’ real status.

**Root Cause**

This is a UI/environment misunderstanding rather than a system or data issue. Entries can have different statuses across different environments, and viewing the entries list/search view rather than the individual entry page for the correct environment can show a status that does not match what an automation is actually consuming from the production environment.

**Resolution**

1.  Confirm which environment your automation is actually reading from (for example, the production/PRD environment specifically).
    
2.  Check entry status from the individual entry page for that specific environment, rather than relying on the entries list/search view, which can display status information that spans or defaults to a different environment.
    
3.  If a “Schedule Publish Failed” flag appears, verify whether it applies to the environment your automation depends on, or to a different (e.g., non-production) environment.
    
4.  Confirm with your automation logs (e.g., what was actually pulled into your downstream system) whether unpublished entries were genuinely ingested, or whether the automation was in fact only pulling correctly published entries all along.
    

Entry status is confirmed per-environment from the individual entry page, clarifying that the automation was processing correctly published entries and the discrepancy was a display/environment mix-up.

### Automation Cannot Be Activated: More Than 10 If-Else Blocks Cause the Automations Page to Crash

An automation with a large number of If-Else conditional blocks cannot be activated. After opening the Automation page, the UI goes blank after a few seconds, and the browser console shows repeated 429 (Too Many Requests) errors from the Automations API followed by an “Invalid array length” JavaScript error.

**Root Cause**

Agent OS currently supports up to 10 If-Else blocks in a single automation. Configuring more than that (for example, 18 blocks) triggers the UI crash described above when the page attempts to render the automation. Support confirmed the 429 errors in the console were not the actual issue in this case, the block count was the limiting factor, though the source ticket does not establish why the 429 errors appear alongside the crash.

**Resolution**

1.  Count the number of If-Else blocks in the automation that will not activate.
    
2.  If the count exceeds 10, reduce the number of If-Else blocks, for example, by consolidating conditions or restructuring logic into fewer branches.
    
3.  If the workflow genuinely requires more than 10 conditional branches, split the logic across multiple automations (using sub-automations or separate triggers) rather than building all branches into a single automation.
    
4.  Reopen the Automation page after reducing the block count to confirm it loads and the automation can be activated.
    

With the If-Else block count at or below 10, the Automation page loads normally and the automation activates without the UI crashing.

## Execution, Code Blocks & Timeouts

### Code Block or Payload Step Appears Skipped During Execution

Automations containing Code Block steps may appear to skip execution or fail to process logic during a run. This often results in downstream actions failing due to missing data from the skipped step.

**Root Cause**  
CodeBlock executions are tracked as a diff count per organization. Once the org's allotted limit is reached, code blocks may be bypassed during workflow execution, resulting in missing fields or incomplete transformations for downstream steps.

**Resolution**

1.  Confirm whether the org has hit its CodeBlock execution (diff count) limit by checking usage in **SuperAdmin**.
    
2.  If the limit has been reached, it can be **increased or decreased per org** via SuperAdmin settings.
    
3.  Adjust the limit to an appropriate value based on the org's workflow requirements.
    
4.  Ask the user to retest the affected workflow after the limit has been updated.
    

Run History shows the code block executing successfully and producing structured output used by downstream steps, with no further skipped steps.

### Duplicated Automation Returns “Rejected” Without Running

After copying an automation, executions may return “rejected” and fail to run even when trigger tests succeed.

**Root Cause**  
Issue self-resolved and could not be inspected due to missing access/log context. Likely transient system or authorization state.

**Resolution**

1.  Re-run the automation after a short interval.
    
2.  If recurrence:
    
    *   Export the automation configuration
        
    *   Provide Run History timestamps and rejection status
        
    *   Share project access with Support for inspection
        

  
Automation runs normally with no “rejected” status.

### Repeat Path Updates Only One Entry (Should Update Many)

Automation iterating over entries updates only the first item, leaving remaining entries unchanged.

**Root Cause**  
Incorrect repeat-path variable reference; the update action was not using the current iteration UID.

**Resolution**

1.  Ensure repeat path is correctly configured to iterate over entry list.
    
2.  Reference the current iteration UID using {{current.value.uid}}.
    
3.  Add a condition to prevent unnecessary updates (e.g., only update if meta\_description is blank).
    
4.  Retest.
    

  
Each entry in the repeat iteration is updated as expected.

### Automation Failures Across Locales Due to Variable-Decoding Edge Case

Automations may fail repeatedly across multiple locales while showing limited troubleshooting detail in the UI, impacting downstream systems (e.g., search indexing).

**Root Cause**  
Backend edge case related to decoding variables when incorrect variable references are used in action configurations.

**Resolution**

1.  Escalate with run IDs and failure timestamps.
    
2.  Engineering applies platform fix for decoding edge cases.
    
3.  Retest the same automation run.
    

  
Runs complete successfully and no longer fail due to variable decoding.

### Lookup Data Error in Automation Action (Non-Reproducible)

Customer reports lookup step error but it cannot be reproduced during validation.

**Root Cause**  
Transient error state; no active failure present during review.

**Resolution**

1.  If error recurs, collect:
    
    *   Lookup step configuration
        
    *   Run ID
        
    *   Error screenshot and timestamp
        
2.  Validate whether lookup source credentials or query parameters changed.
    

  
The lookup step completes successfully without runtime errors.

### Automation Failure Due to 300-Second Code Block Execution Timeout

Automations may fail at certain time windows when processing large datasets due to code block runtime constraints.

**Root Cause**  
Automation Hub enforces a **300-second execution timeout**, and the workload exceeded what could be completed in that window.

**Resolution**

1.  Reduce items processed per run (batching).
    
2.  Split into multiple executions:
    
    *   Use pagination/skip/limit
        
    *   Store cursor state externally
        
3.  Optimize code block performance:
    
    *   Minimize sequential HTTP calls
        
    *   Prefer bulk endpoints where possible
        

  
Run History shows successful completion within the timeout, with full workload processed across batches.

### Updating Multiline Text Field With Stringified JSON Causes Payload Type Error

When an automation attempts to store JSON inside a multiline text field by injecting a stringified JSON variable, the update action may fail because the platform interprets the injected content as an object instead of a string.

**Root Cause**  
Variable injection and JSON rendering in automation payloads can cause a “stringified JSON” to be treated as a JSON object unless explicitly escaped.

**Resolution**

1.  In the script/code step, apply **double serialization**:
    
    *   JSON.stringify(JSON.stringify(obj))
        
2.  Confirm the resulting payload includes proper quoting when embedded in outer JSON.
    
3.  Retest the Update Entry action.
    

  
Entry updates successfully, and the multiline text field contains the intended JSON string (not a parsed object).

### Agent OS Monthly Execution Limit Reached: Automations Temporarily Disabled

Automations stop running and Contentstack sends a notification that the organization has reached its monthly Agent OS execution limit. New executions fail or are queued until the limit resets.

**Root Cause**

Every organization has a monthly automation execution allowance, made up of a soft limit and a hard limit (for example, automation\_exec\_soft\_limit and automation\_exec\_hard\_limit set to 2,000 on a given plan). Trial organizations default to a much lower allowance, around 200 executions, while environments such as Azure can carry a higher hard limit (up to 125,000). Activities such as bulk migrations, testing scripts that trigger many entry updates, or an unexpected spike in publish/update events can consume the allowance faster than expected, and once the hard limit is hit, Agent OS is disabled for the organization until the monthly reset.

**Resolution**

1.  Open the Execution Log for your Agent OS organization to confirm which automations are consuming executions and when the spike occurred.
    
2.  If the consumption is expected (for example, a planned migration or a temporary testing spike), contact Contentstack Support with your Organization ID and request a temporary increase to the soft or hard execution limit.
    
3.  If you are in a trial organization and need a substantially higher ceiling, ask Support whether moving to a production environment (such as Azure) is applicable, since some environments carry a higher default hard limit.
    
4.  For one-off spikes caused by internal testing rather than normal usage, ask your Customer Success Manager whether the affected executions can be excluded from the usage count as a one-time courtesy.
    
5.  Once the limit increase is confirmed, resume the operation that required the higher allowance. If the increase was temporary, confirm with Support or your CSM when it reverts to the standard limit.
    

After the limit is increased or the monthly reset occurs, previously blocked automations resume executing and no further execution-limit notifications are received for the affected activity.

### Execution Count in Product Analytics Doesn’t Match the Execution Log

The number of automation executions shown on the Product Analytics dashboard is noticeably lower than the count reflected elsewhere (for example, in a limit-reached notification), leading to confusion about actual usage.

**Root Cause**

The Product Analytics dashboard does not update in real time, it typically reflects execution data with a delay of around 24 hours, and the backend records execution timestamps in UTC while the dashboard displays only the date, not the time. Both factors mean the dashboard total can trail behind, or appear to fall on a different day than, the true count.

**Resolution**

1.  Do not rely on the Product Analytics dashboard alone to confirm current-month usage against your execution limit.
    
2.  Open Agent OS Execution Log, which reflect executions as they happen and are the source of truth for accurate, granular execution data.
    
3.  When comparing totals across a day boundary, account for the fact that the backend logs execution times in UTC, which can shift a batch of executions into a different calendar day than what the dashboard shows.
    
4.  If the discrepancy persists after allowing for the ~24-hour dashboard delay, contact Contentstack Support with the specific date range in question.
    

Execution Logs and the limit-reached notifications now agree, and any apparent discrepancy is explained by the dashboard’s reporting delay and UTC timestamping.

### Automation Works When Testing Manually, but Fails or Behaves Inconsistently Once Enabled

An automation runs correctly every time it is triggered manually through Test, but once enabled for live use, executions are inconsistent: some expected branches never run, entries appear to be skipped, or bulk operations that use the automation start failing.

**Root Cause**

Live triggers (such as publish) can fire far more frequently and in bigger bursts than manual test runs, especially during bulk operations. This drives requests past the CMA write-request limit (20 requests per second), producing 429 “Rate limit exceeded” errors, and a single publish or entry change can fan out into multiple triggers running in parallel, which increases the chance of hitting that ceiling and causing inconsistent branch execution under load.

**Resolution**

1.  For bulk operations (e.g., publishing many entries at once), trigger the automation off a job rather than off each individual entry or reference, so it does not execute once per entry.
    
2.  Add **Wait** steps between API-heavy steps in the automation to spread out requests instead of firing them in a tight burst.
    
3.  Enable **Throttle Execution** in the Agent OS settings for the automation; this paces requests automatically through an internal queue rather than requiring a manual per-second value.
    
4.  Review the Execution Logs for the automation and filter for 429 errors to confirm rate limiting is the cause of the inconsistent behavior.
    
5.  Narrow the publish queue or trigger filters so the automation only fires on the specific entry types or events it needs to handle, reducing unnecessary trigger volume.
    
6.  After making these changes, re-run the live workflow and review one full execution log to confirm the branches you expect to run are all completed.
    

With a job-based trigger, throttling, and **Wait** steps in place, the automation completes its expected branches consistently under live load, and the Execution Logs no longer show 429 errors for the affected automation.

### Automation Step Fails with “Cannot Find Module” Error

Saving a trigger or running an automation step fails with an error similar to: Cannot find module /opt/automations-workflow-engine/connectors/<id>/<id>.js, pointing into the automations workflow engine’s internal file structure.

**Root Cause**

The step or trigger references a connector module path that is not present, or not generated, on the workflow engine, a stale or broken connector registration for that specific step.

**Resolution**

1.  Delete the failing step (or trigger) from the automation.
    
2.  Re-create the step using the same step type and configuration it had before.
    
3.  Re-run or re-save the automation to confirm the error no longer appears.
    
4.  If deleting and re-creating the step does not resolve the error, contact Contentstack Support with the automation ID, step ID, connector/account in use, and the timestamp of the failure so it can be investigated on the engine side.
    

The step saves and runs successfully after being deleted and re-created, with no “Cannot find module” error.

## Actions, Publishing & Endpoints

### Validating Automation Design for External Backend Integration

Automating a workflow that triggers based on content updates and sends data to an external backend service may fail if the design does not account for platform limitations. Improperly configured triggers and actions can result in execution errors or unintended loops.

**Root cause**  
The issue stems from a design validation requirement where the automation logic must be verified for feasibility within Agent OS, rather than a specific product defect.

**Resolution**

1.  Confirm the intended use case is supported by existing triggers and connectors.
    
2.  Align the automation workflow with best practice patterns for external API integrations.
    

⚠️ **Important:** Ensure the source content type is different from the target content type. Using the same content type for both will cause an infinite loop.

After configuring the workflow pattern, run a test execution by updating a sample entry. If the payload is received correctly by the backend and no loops occur, the issue is resolved. Escalate with workflow configuration screenshots and execution logs if the issue persists.

### Schedule Publishing Based on a Countdown/End-Date Field (and Maintain Schedule on Updates)

Customers often need content to auto-publish at a defined “end date/time” stored in an entry field, and to automatically update/cancel scheduled jobs if that field changes.

**Root Cause**  
This requires two controlled automation paths: one for new entries and another for updates, including schedule cancellation logic using publish details/job IDs.

**Resolution**  
**A) For New Entries**

1.  Trigger: Entry Create (relevant content type).
    
2.  Step: Read end-date field from payload.
    
3.  Step: Schedule publish action for the same entry at the end-date timestamp.
    

**B) For Updated Entries**

1.  Trigger: Entry Update (same content type).
    
2.  Fetch previous entry version (CMA) including publish\_details.
    
3.  Compare previous end-date vs current end-date (code step).
    
4.  If changed:
    
    *   Identify scheduled job in publish\_details matching old scheduled\_at.
        
    *   Cancel scheduled job using job\_id via CMA cancel schedule endpoint.
        
    *   Schedule publish with new date.
        

**Verify**

*   New entries are scheduled correctly at the field timestamp.
    
*   Updated entries replace the prior scheduled job with the updated timestamp.
    
*   No duplicate schedules remain active.

### Requirement to Capture Publisher Email on Publish Event

Customers want automation to obtain the publishing user’s email when an entry is published and use it for notifications or audits.

**Root Cause**  
The requested attribute may not be available directly in the expected form in the automation payload or may require an alternate extraction approach.

**Resolution**

1.  Confirm what the trigger payload contains (user UID vs email).
    
2.  If only UID is present, resolve user details via a management API call in a code/HTTP step (subject to permissions).
    
3.  Use Email action connector to send notifications using resolved email.
    

  
Automation reliably retrieves publisher identity (email or resolved identifier) and uses it in notifications.

### Automation Actions Display as Performed by a User, Not the Management Token

Automation actions (e.g., publish) may show attribution to a named user even when using a management token, which can create audit concerns.

**Root Cause**  
Attribution is tied to the account selected during automation configuration, not to the token identity.

**Resolution**

1.  Identify which user account is selected in automation configuration.
    
2.  If audit alignment is required, use an approved service account for automation ownership.
    
3.  Log enhancement request if token-based attribution is required.
    

  
Action attribution aligns with the configured automation owner account.

### AWS S3 Agent OS Connector Throws “Invalid Credentials” Even Though the Credentials Are Correct

The AWS S3 connector in Agent OS returns an “Invalid Credentials” error even though the same credentials work correctly in an unrestricted environment. This typically appears once an S3 bucket has strict security policies applied, such as an IP allowlist.

**Root Cause**

The Agent OS S3 connector uses the official AWS SDK, which surfaces a generic “Invalid Credentials” message for a range of IAM restrictions, not just bad keys, including missing permissions and IP-based restrictions. Because Contentstack’s infrastructure connects to S3 through a VPC endpoint, traffic often travels over the AWS internal network rather than the public internet. Whitelisting Contentstack’s public IP addresses does not cover this internal path, so a bucket policy that only allows specific public IPs still blocks the connection.

**Resolution**

1.  Confirm that the credentials themselves are valid and have the required S3 permissions (including any needed for DeleteObject if your workflow uses it).
    
2.  If your bucket policy uses an IP allowlist, do not rely solely on whitelisting Contentstack’s static public IP addresses, since traffic may route over AWS’s internal network via a VPC endpoint instead of the public internet.
    
3.  Request Contentstack’s VPC endpoint ID from Support and add it to your bucket or IAM policy so the internal network path is authorized.
    
4.  Retest the S3 connector after updating the policy to confirm the “Invalid Credentials” error no longer appears.
    

The S3 connector authenticates successfully and the connection remains stable, because the bucket policy now authorizes Contentstack’s VPC endpoint rather than only its public IP addresses.

### AWS Bedrock Prompt Connector Doesn’t Show a Model That Is Enabled in Your AWS Console

A model (for example, an Anthropic Claude model in AWS Bedrock) is enabled in your AWS console, but it does not appear in the Foundation Model drop-down of the AWS Bedrock Prompt connector step in Agent OS.

**Root Cause**

The AWS Bedrock Prompt connector originally populated its model dropdown using the ListFoundationModels API. AWS has since moved some newer Anthropic models to the ListInferenceProfiles API instead, which means those models are invisible to versions of the connector that only call ListFoundationModels.

**Resolution**

1.  Confirm in your AWS console that the model is enabled and that you can see it under Bedrock’s inference profiles (not just foundation models).
    
2.  Delete the existing AWS Bedrock Prompt step in your automation and re-add it; this refreshes the step to the current connector version, which supports the ListInferenceProfiles API.
    
3.  If, after re-adding the step, you get an error that “on-demand throughput isn’t supported” for the model, this means the model requires a global inference profile rather than on-demand throughput, select or configure the appropriate inference profile for that model.
    
4.  Re-test the prompt step to confirm the model can now be fetched and used to generate output.
    

The model appears in the **Foundation Model** dropdown, and the AWS Bedrock Prompt step successfully generates output using it.

### Vertex AI Connector: Project Selection Fails After Successful Service Account Authorization

In an Automation step using the Vertex AI connector, the service account is added and successfully validated through the “Authorize” button, but an error occurs when trying to select a Google Cloud project, blocking further configuration of the step.

**Root Cause**

The service account does not have all of the Google Cloud APIs required for project listing and Vertex AI usage enabled, and/or its IAM role does not include the permission needed to list projects.

**Resolution**

1.  In your Google Cloud project, enable the Cloud Resource Manager API (cloudresourcemanager.googleapis.com), this is required for listing and fetching your Google Cloud projects in the connector UI.
    
2.  Enable the Vertex AI API (aiplatform.googleapis.com), this is required for sending prompts and using Gemini or function calling on Vertex AI.
    
3.  If your workflow uses catalog or product operations, also enable the Retail API (retail.googleapis.com); skip this if you are not using commerce features.
    
4.  Verify that the service account (or connected Google account) has an IAM role of at least Viewer, Browser, or Editor/Owner, or a custom role that includes the resourcemanager.projects.list permission.
    
5.  Allow time for the API and IAM changes to propagate, then return to the Vertex AI connector step and retry project selection.
    

After the required APIs and IAM permissions are in place, the connector can list and let you select your Google Cloud project without error.

### Agent OS Elasticsearch Connector Authentication Fails with Username/Password

Setting up an Agent OS job to connect to an Elasticsearch connector fails because the Username and Password fields do not accept the credentials being entered, and it is unclear whether API-key-based authentication is supported instead.

**Root Cause**

The connector requires the **Node URL**, **Username**, and **Password** from the specific Elasticsearch deployment’s connection details, credentials that are automatically generated at the time the deployment was created, rather than a separately created API key.

**Resolution**

1.  Go to your Elasticsearch deployment page and locate the **Node URL** for the deployment.
    
2.  Retrieve the **Username** and **Password** that were automatically generated when the deployment was created (these are deployment-specific, not a separate API key).
    
3.  Enter the **Node URL**, **Username**, and **Password** exactly as shown on the deployment page into the Agent OS Elasticsearch connector fields.
    
4.  Refer to the Elasticsearch connector documentation specifically the credentials step, if you are unsure which deployment page fields to use.
    
5.  Retest the connection after entering the deployment-specific credentials.
    

The Elasticsearch connector authenticates successfully using the deployment’s **Node URL**, **Username**, and **Password**.

### Fetching Entries Published Within a Specific Time Period Using Agent OS

There is no direct, built-in way to fetch only the entries that were published within a specific recent time window (for example, the last N days) from within an Automation.

**Root Cause**

The **Get Publish Queue** action only returns a limited number of recent publish events by default (10), which is not enough to reliably capture and filter entries published over a longer or configurable period.

**Resolution**

1.  Add a **Get Publish Queue** action to your automation and increase its result limit beyond the default of 10 to capture a wider window of publish events.
    
2.  Add a **JavaScript Code** step (V9) after the **Get Publish Queue** action.
    
3.  In the **JavaScript Code** step, filter the returned entries dynamically based on their published\_at date, using a configurable number of days as the cutoff.
    
4.  Test the automation to confirm it returns only entries published within your intended time period.
    

The automation returns exactly the entries published within the configured time window, based on the published\_at field.

### Sending Agent OS Email Notifications After Content Deployment

There is a need to notify a distribution list automatically after content is deployed to production, and it is unclear which Contentstack features support this.

**Root Cause**

Contentstack does not send post-deployment email notifications automatically out of the box; this needs to be configured using either Agent OS or an external notification service triggered via a webhook.

**Resolution**

1.  Option 1: Agent OS, create an automation with a publish trigger on the relevant content type/environment, and add an email action to that automation to notify your distribution list when the trigger fires.
    
2.  Option 2: Webhooks, configure a Contentstack webhook on the relevant publish event, and integrate it with an external service such as Amazon SNS or SendGrid to handle sending the notification email.
    
3.  Choose whichever option better fits your existing tooling, Agent OS’s email action for a self-contained setup, or Webhooks plus an external service if you already use SNS/SendGrid for notifications elsewhere.
    
4.  Test the trigger by publishing a sample entry to confirm the notification email is sent as expected.
    

The distribution list receives an email notification automatically whenever content is deployed to production through the configured trigger.

### Automating User Access Provisioning and De-Provisioning

There is a need for Agent OS granting and removing user access to stacks and roles in Contentstack based on an internal request workflow (for example, requests submitted through ServiceNow), and it is unclear whether Contentstack supports this natively.

**Root Cause**

Contentstack does not provide a native, built-in ServiceNow integration for Agent OS user provisioning or de-provisioning.

**Resolution**

1.  Use the Contentstack Management API to build the integration instead of looking for a native ServiceNow connector.
    
2.  Use the Management API’s user-invite endpoints to add or invite users programmatically when your internal workflow approves a request.
    
3.  Use the Management API to assign or update roles for a user based on the access level requested in your internal workflow.
    
4.  Use the Management API to remove a user’s access when your internal workflow triggers a de-provisioning request.
    
5.  Connect these Management API calls to your internal workflow (for example, via a script or middleware that ServiceNow can call) so provisioning and de-provisioning happen automatically end-to-end.
    

Access requests submitted through your internal workflow result in the corresponding user being added, role-assigned, or removed in Contentstack automatically, via the Management API.

### Identifying Which Automation or Webhook Made an Unexpected Content Update

Entries appear to be updated (new versions created) without any user actively saving or publishing them, and it is unclear which automation or webhook is responsible.

**Root Cause**

Updates performed by an automation or an external script using the Management API are recorded under the relevant automation’s identity (for example, “Syndication Automation”), not under a human user’s name, which can make the change look like it happened at random if you are only checking for manual user activity.

**Resolution**

1.  Go to Agent OS Execution Log in your stack to see which automations ran and at what time.
    
2.  Cross-reference the timestamps of the unexpected updates with the Execution Log to identify the specific automation responsible.
    
3.  Check Agent OS Activities in the Audit Log for a detailed view of the actions each automation performed, including which entries were affected.
    

The Execution Log and Audit Log identify the specific automation (or external script) responsible for the update, resolving the “random” update behavior.

### Copying Entries Between Locales Using Agent OS Instead of Manual Export/Import

Content created in the wrong locale (for example, entries mistakenly created in Italian instead of English) needs to be copied to the correct locale, and it is unclear whether this can be Agent OS or must be handled through a manual export/import.

**Root Cause**

This is not a defect, Agent OS supports building a workflow for this use case, so a manual export/import is not required.

**Resolution**

1.  Create an Agent OS workflow that uses a **Get an Entry** action to retrieve the entry from the source locale (for example, Italian).
    
2.  Add an **Update an Entry** action targeting the target locale (for example, English), and map the fields from the source entry to the corresponding fields on the target locale entry.
    
3.  Optionally, add conditions to control which entries are processed, and a publish step if the copied entries should be published automatically.
    
4.  Note that references and assets do not need special handling in this mapping, since they are UID-based and remain intact across the copy.
    
5.  Run the workflow and confirm the target-locale entries now contain the expected field values.
    

Entries created in the wrong locale are copied into the correct locale with their field values, references, and assets intact, without a manual export/import.

## Architecture, Recipes & Supported Workflows

### Recipe Import Fails With “Recipe Was Not Found”

When importing an Automation Hub recipe (for example “Translate and Localize an Entry”), the import link may return a “recipe was not found” error and the recipe does not get added to the project.

**Root Cause**  
The recipe import link was broken/invalid at the time of import.

**Resolution**

1.  Retry the import using the same recipe link after confirmation that the link has been restored.
    
2.  Validate the import from a supported browser session (try incognito to rule out cached stale redirects).
    
3.  If it still fails, provide Support with:
    
    *   Recipe name
        
    *   Import URL used
        
    *   Timestamp and screenshot of the error
        

  
The recipe imports successfully and appears under the target project with all steps available.

### Automation Review Call Request

Customer requests a follow-up call for additional automation configuration questions, typically after resolving a prior issue.

**Root Cause**  
General advisory request; no defect.

**Resolution**

1.  Request agenda and automation links (project + automation name).
    
2.  Validate the configuration and explain best practices for triggers/actions.
    
3.  Confirm closure once questions are answered.
    

  
The customer confirms the configuration is correct and proceeds without further blockers.

### Using Automation Hub to Sync Content Across Different Stacks

Customer attempts to use Automation Hub to synchronize entries between two different stacks and observes that content does not copy or update as expected.

**Root Cause**  
Automation Hub supports workflows within the same stack context (including branches), but cross-stack content sync is not supported.

**Resolution**

1.  Confirm whether source and target are different stacks.
    
2.  For cross-stack sync:
    
    *   Use Contentstack CLI export/import
        
    *   Consider stack cloning where applicable
        
3.  If partial automation is desired, use external middleware to orchestrate cross-stack CMA calls.
    

  
Content sync is achieved using CLI-based export/import or approved migration approach.

### Contentstack MCP Server Supports Only One Stack per Agent Configuration

When configuring an agent to use the Contentstack MCP server, only a single CONTENTSTACK\_API\_KEY can be provided, and there is no way to manage entries or assets across multiple stacks from that one agent configuration.

**Root Cause**

The current MCP configuration accepts one CONTENTSTACK\_API\_KEY per agent, and that key is tied to a single stack. Multi-stack management within a single MCP configuration is not supported natively.

**Resolution**

1.  If you need an agent to work across multiple stacks, configure a separate MCP instance for each stack, each with its own CONTENTSTACK\_API\_KEY.
    
2.  Alternatively, build an external orchestration layer or application that routes requests to the correct stack-specific MCP agent based on which stack a given request needs.
    
3.  Design your agent workflows around whichever of the above matches your architecture, since a single MCP agent instance operates only within the one stack its API key belongs to.
    

Each MCP agent instance operates correctly within its assigned stack, and cross-stack operations are handled by routing between multiple stack-specific instances rather than expecting one instance to span stacks.

### Planning a Large Bulk Migration Through Agent OS Without Hitting Rate Limits

Ahead of a large migration (for example, importing more than 10,000 entries) driven by an Automation, initial testing shows each execution taking several seconds, raising concern that the volume and pace could trigger rate limits or a failure loop during the live migration. Enabling “Throttle Execution” in the settings does not show any per-second or per-minute field, which adds to the uncertainty.

**Root Cause**

Throttle Execution does not expose a manual per-second or per-minute input because it works differently: once enabled, it uses an intelligent internal queue that paces requests automatically based on system capacity, rather than requiring you to configure a fixed rate yourself.

**Resolution**

1.  Enable **Throttle Execution** in the automation’s settings before running the migration.
    
2.  Do not look for or expect a manual per-second/per-minute rate field, the internal queue handles pacing automatically once the setting is on.
    
3.  Before running the full migration, run a smaller test batch (for example, around 500 entries) through the same automation.
    
4.  Monitor the Execution Log during the test batch to confirm executions complete without rate-limit failures, even if individual executions are slow.
    
5.  Once the test batch completes cleanly, proceed with the full migration using the same throttled configuration.
    

The full migration completes without triggering rate-limit failures, because **Throttle Execution** paces requests automatically rather than sending them all at the execution’s native (slower) pace in an uncontrolled burst.

### Automation Step Limit Reached When Building Large Workflows

A workflow that needs many steps, for example, 28–50 steps to handle onboarding across multiple entry types, hits Agent OS’s step limit before the full workflow can be built, or the customer needs guidance on splitting the work.

**Root Cause**

Agent OS enforces a step limit per automation. Support can raise this limit up to 15 steps without engineering approval; anything beyond 15 steps requires engineering sign-off.

**Resolution**

1.  If your automation needs more than the default number of steps, contact Contentstack Support with your use case and request a step limit increase.
    
2.  Support can approve an increase up to 15 steps directly. If you need more than 15, be prepared for the request to be routed to engineering for approval.
    
3.  Before requesting a large increase, review whether the workflow can be restructured using sub automations, which let you split a large process into smaller automations that call each other rather than building one very long automation.
    
4.  One customer raised whether consolidating into a single **Repeat Path** per entry type could reduce total step count (e.g., from 42 to 28) for an equivalent outcome, this was not independently confirmed by Contentstack, so treat it as untested and validate the step count change on a copy of the automation before relying on it.
    

The automation either fits within the approved step limit or has been split into sub-automations that together cover the same workflow without exceeding platform limits.