Support

Bug reports

Use GitHub Issues for non-sensitive bugs.

Good bug reports should include:

• WrightTest version.
• Git commit if available.
• Deployment type: Docker, local development, or other.
• Affected page or feature.
• Steps to reproduce.
• Expected behavior.
• Actual behavior.
• Screenshots if helpful.
• Relevant logs without secrets.

GitHub Issues: https://github.com/AlexFilippov-it/wrighttest/issues

Feature requests

Use GitHub Issues for feature requests.

Please include:

• The problem you are trying to solve.
• The workflow affected.
• Why the current behavior is not enough.
• Examples or screenshots if useful.

Example requests can include a new assertion type, better schedule options, a new alert provider, an import or export improvement, or a trace or debugging improvement.

Documentation issues

If documentation is outdated, unclear, or missing important details, open a GitHub issue.

• The page URL.
• What is confusing or incorrect.
• What behavior you expected to find documented.

If the docs need a rewrite or a new example, that is helpful too.

Security reports

Do not open public GitHub Issues for vulnerabilities.

Security-sensitive issues may include credential exposure, authentication bypass, unauthorized access to run artifacts, leaked screenshots or traces, exposed alert tokens or webhook URLs, or access to projects without permission.

For security-sensitive reports, use GitHub Security Advisories if available. If a dedicated security contact is added later, it will be listed on the Security page.

Security page: /security

What to include in a support request

When reporting a problem, include as much context as possible.

WrightTest version:
Git commit:
Deployment:
Browser:
Project:
Check:
Run ID:
Page URL:
Error message:
Steps to reproduce:

If the issue is related to a failed run, include:

Run ID:
check name:
failed step number:
short error summary:
whether screenshots are available:
whether trace is available:

What not to include

Do not include secrets in public reports.

• .env files.
• Database URLs.
• Redis URLs.
• Passwords.
• Telegram bot tokens.
• Slack webhook URLs.
• Screenshots with private user data.
• Trace files that contain sensitive information.
• Internal production URLs, unless they are safe to share.

If sensitive data was exposed, rotate the affected secret immediately.

Before opening an issue

Before reporting a bug, check Troubleshooting, Configuration, Release notes, and existing GitHub Issues.

This helps avoid duplicate reports and makes the issue easier to solve.

Response expectations

WrightTest is currently a source-available project. Support is handled on a best-effort basis through public project channels.

Do not rely on guaranteed response times unless a separate support agreement exists.

Related pages