Skip to main content
Use this page when something in Arcus is broken, blocked, confusing, missing, or behaving differently than expected. A strong bug report helps the Arcus team reproduce the problem, understand the business impact, and decide whether it needs an urgent fix, workflow clarification, or follow-up question. Bug reports are best for current behavior that should work but does not. If you want a new workflow, new field, new integration, or a better way to complete an existing task, use Feature Request instead.
Do not submit passwords, API keys, access tokens, full payment details, or private customer information. If a screenshot is needed, crop or redact anything sensitive first.

Good bug reports include

The Arcus page, tab, modal, order number or product area, steps to repeat, expected behavior, actual behavior, and whether the issue blocks work.

What happens next

The Arcus team reviews the report, checks whether the issue can be reproduced, and follows up if more detail is needed.

​
Before You Submit

Check the page one more time after refreshing Arcus. If the issue happens only after a specific action, include that action in the steps. If the issue affects an order, product, shipment, return, journal entry, connector, or report, include the order number, SKU, report name, or other safe reference that helps support find it. Useful examples:
  • “Orders > Packing: buying a Shippo label fails after rate shopping UPS Ground.”
  • “Products > Inventory: bin quantity shows available stock, but the order still backorders.”
  • “Accounting > Reconciliation: matched payout disappeared after I changed the date filter.”
  • “Customer portal: public invoice link opens, but payment methods do not load.”
Screenshots help, but they must be safe to share. Crop customer addresses, phone numbers, emails, full card details, access tokens, and secret keys before submitting.

​
Report Form