Guides

Troubleshooting

Debug publish, activation, runtime, job, webhook, secret, and rollback failures.

For agents: Start with publish output, activation status, missing secrets, release resources, and account-visible app events.

Checks

  1. Confirm USERLAND_API_KEY is set only in the local environment, or run userland auth status to verify saved CLI credentials and selected account.
  2. Confirm the selected platform account when publishing or listing team/client apps.
  3. Validate manifest.userland.json.
  4. Check activation status for pending_secrets or requires_migration.
  5. Read app events with userland apps events "$APP_ID" --severity error.
  6. Roll back only to a compatible retained release.

If a team/client app is missing from apps list, run userland accounts list and check whether USERLAND_ACCOUNT_ID, --account, or a saved account_id is selecting a different account.

If you need help from Userland, run userland support open --subject "..." --message "..." --app "$APP_ID" or open Support in the console. The support request includes account context and prints a correlation_id for follow-up.

403 on CLI/API operations means the authenticated actor belongs to the app’s platform account but their account role cannot perform the operation. App-user roles such as admin or editor only apply inside the published app runtime. 404 can mean the actor is not a member of the app’s owning account.

402 means the selected account is allowed to make the request, but its plan does not include the feature or limit. Check error.details.violations for manifest paths such as /app/visibility, /resources/jobs/*/schedule, or /resources/webhooks/*/provider.

Auth and CLI Credentials

Userland platform auth is passwordless. The console signs in with email links, the CLI signs in with browser-approved device authorization, and app/API operations use API keys. There is no platform password reset flow.

Legacy password endpoints intentionally return 410 with password_auth_disabled or password_signup_disabled. Do not use /v0/auth/token, /v0/platform/sessions, password reset request/confirm, or unauthenticated POST /v0/accounts for launch auth.

First Commands

userland apps events "$APP_ID" --limit 25
userland apps releases "$APP_ID"
userland apps secrets set "$APP_ID" SECRET_NAME --value "$VALUE"
userland apps rollback "$APP_ID" "$RELEASE_ID"

Publish failures

Activation failures

pending_secrets means the release is stored but not live. Set each missing secret:

printf '%s' "$VALUE" | userland apps secrets set "$APP_ID" SECRET_NAME

requires_migration means the release changes durable resources in a way v0 will not apply automatically. Use an add/backfill/hide approach: add a new resource name, backfill in runtime code or an admin path, then stop using the old resource.

Runtime failures

Read recent error events:

userland apps events "$APP_ID" --severity error --limit 25

Check that dynamic routes are reachable only when fallback is server, that the server module exports fetch, and that frontend code calls your app origin rather than the control-plane API.

Job and Webhook Failures

Check events for the job or webhook name, then compare the manifest with server/index.js:

userland apps events "$APP_ID" --type job --limit 25
userland apps events "$APP_ID" --type webhook --limit 25

Job names must match exactly. Webhooks that deliver to jobs must reference a declared job and a required secret that has been set for the app.