Preparing a support request: the right information for a faster investigation

1. Identify the impact and affected service

Specify the domain, page or email account where the error occurs. Does it affect every user, a particular account or only your connection? If possible, check once from another device or network. Do not run a load test on any website or system without permission.

Include the service or order number from the customer portal. For agencies managing multiple client projects, saying only 'my website is not loading' leaves the account to investigate unclear. Report independent issues under separate subjects, and add new findings about the same issue to the existing ticket.

2. Record the time and recent changes

Specify the approximate date, time and time zone when the issue began. Use a clear statement such as '18 October 2026, 14:20, Istanbul time' instead of 'just now' so server logs can be reviewed for the right interval. This is only an example of wording; enter the time of your own incident.

Include recent changes to DNS, passwords, PHP versions, themes, plugins, code or the firewall. If you do not know for certain that a change caused the error, identify it as a hypothesis. Also describe the steps you have tried so they are not repeated unnecessarily.

3. Include the error text and relevant evidence

Record the browser error code, application message or email delivery failure notice exactly as shown. If sharing a screenshot, hide user information, client data and secret keys. If the issue occurs only in a particular workflow, number the steps to reproduce it.

Share the necessary lines from the relevant time interval instead of the entire log file. Do not include records containing session cookies, Authorization headers, passwords, database connection secrets or recovery codes in a support message.

4. Prepare your request with this template

Service / order number:
Affected domain or application:
URL where the error occurs:
Start time and time zone:
Affected users / functions:
Visible error message:
Steps to reproduce:
Most recent change:
Steps tried and their results:

You do not need a long explanation in every field. If you do not know something, state 'not determined' instead of guessing. Explain clearly what you expected to work and what happened instead.

5. Submit through the right channel

Use the customer portal for your existing service. This keeps account ownership procedures and request history in one place. If you cannot access your account, report the access issue through the contact form.

For phishing, malicious content or another abuse incident, use the abuse reporting channel. If you believe you have found a vulnerability, do not access other people's data or run tests that affect the service to verify it.

6. Verify the resolution and complete the record

Understand the impact of a change suggested by support before applying it; take a current backup for operations that require one. If access is needed, use a temporary account with limited permissions where possible. Remove temporary access when the work is complete.

Retest the actual step where the problem occurred, not just whether the homepage loads. For email, check both receiving and sending; for an application, check the relevant user role. Add the result to the same support ticket to complete the process.

An example of a brief but actionable report

Educational example — not a real customer incident:
Subject: HTTP 500 on example.com /contact page
Expected: Contact form loads
Observed: Homepage loads, /contact returns 500
Time: Enter the incident date, time and time zone here
Scope: Seen on the same page from two different networks
Recent change: Form plugin updated; not yet confirmed as the cause
Attachment: Relevant error line from the affected interval, with no sensitive data

This format separates the observed error from the assumed cause. If you do not yet know which layer has the issue, add an initial finding by distinguishing DNS, TLS and HTTP.