Get help

Use the documentation and exact error message first. If the issue remains, send support enough evidence to reproduce it safely.

A useful support request explains one observable problem from beginning to end. It identifies the project, environment, time, action, and result without asking support to guess which account or screen was involved. Good evidence shortens the investigation and reduces the chance of changing the wrong thing.

Before contacting support, try the narrow safe action described in Troubleshooting, such as one refresh or checking the selected project's status. Do not reboot services, repeat payments, or send duplicate builds simply to create more evidence.

Example: “Project 354, Preview on iPhone Safari, Aug 6 around 4:20 PM Pacific. The server changed to Online, but the warm-up loader remained until I refreshed. Desktop Chrome transitioned normally.”

Include

• your Mango9 account email or company name;
• project name and visible project ID;
• approximate time and timezone;
• page or route;
• browser and device;
• the action you performed;
• expected and actual result;
• screenshot or recording;
• exact non-secret error text;
• whether the issue is in Preview or the published app.

Put these details into a short timeline. Start with the page you opened, then the action, then what you expected and what appeared instead. If the issue is intermittent, say how many times it happened and whether the same steps ever succeeded.

Use screenshots to show the visible state, but also type the important error text so it can be searched. Crop the image to the relevant area and remove unrelated personal information, browser tabs, balances, or customer records.

Example: “At 10:53 PM I opened project 358, selected two planner answers, and pressed Continue. I expected the saved Brief card. Instead, the same question returned. It happened twice in Safari 18 on iPhone.”

Do not include

• passwords;
• database connection strings;
• API keys or webhook secrets;
• session cookies;
• one-time login or signup-intent links;
• private customer data that is not needed to reproduce the issue.

Support evidence should prove behavior, not transfer authority. Passwords, session cookies, private keys, database URIs, and one-time links can let someone act as the account and should never be included. Redact them even when the error screen displays part of a value.

Use test records whenever possible. If a real customer's situation is essential, provide only the minimum identifier support needs and follow the approved support channel for sensitive data.

Example: Send “Webhook signature verification failed at 2:14 PM” instead of copying the webhook secret or full signed request into email.

Contact

Email support@mango9.com from the address associated with your account. If the issue affects production availability, say so in the subject and include the production hostname.

Keep one issue in one thread so timestamps, questions, and resolution stay together. Start a separate message for an unrelated product request. If the problem stops, reply with what changed; intermittent success is useful evidence rather than a reason to abandon the report.

For production impact, state whether all users are affected, one role is affected, or only one workflow is failing. This helps support distinguish a full outage from a permission, browser, or provider-specific problem.

Example: “Production issue — portal.example.com — members cannot submit forms; admins can still sign in.”

Suggested subject:

Production issue — project 123 — checkout returns an error

Mango9 support uses authorized support tooling and role controls. Do not send credentials or approve an unexpected login request.