How to Report a Bug or Technical Issue

Reporting Technical Problems Effectively

When you encounter a bug or technical issue that you can't resolve on your own, reporting it properly helps our team identify, reproduce, and fix the problem faster. This guide explains how to gather the right information, where to submit reports, and what details to include for the most effective bug reporting.

Identifying a Bug vs. Expected Behavior

Before reporting something as a bug, it's worth confirming whether it's actually unexpected behavior. Bugs are functional problems where something doesn't work as designed—features that crash, produce errors, lose data, or behave inconsistently. Missing features or functionality you'd like to see aren't bugs—they're feature requests, which are tracked separately.

Check our documentation to verify the behavior you're expecting is actually how the feature should work. Sometimes users encounter limitations or design decisions that seem like bugs but are intentional. Our knowledge base, video tutorials, and feature documentation explain how everything should function. If the documentation describes different behavior than what you're experiencing, that's a strong indicator of a genuine bug.

Look for existing reports of the same issue in our community forums or known issues page. Many bugs are already identified and being worked on. Duplicate reports don't speed up fixes—they just create extra work for our support team. If you find an existing report for your issue, upvote or comment on it to show it's affecting multiple users, which helps us prioritize.

Gathering Information Before Reporting

Quality bug reports include specific information that helps developers reproduce and fix the issue. Start by documenting the exact steps to reproduce the problem. Try to perform the action multiple times to confirm it's reproducible rather than a one-time glitch. Write down each step you take, from logging in to the action that triggers the bug. Developers need to recreate the exact scenario to debug effectively.

Record any error messages verbatim, including error codes or reference numbers. Screenshots of error messages are extremely helpful—they capture details you might miss when manually typing error text. If the bug involves visual problems, take screenshots or screen recordings showing the issue. A picture is worth a thousand words when describing layout issues, display problems, or unexpected UI behavior.

Note your environment details: what browser you're using and its version number (found in browser settings), your operating system and version, what device you're on (desktop, laptop, tablet, phone), screen resolution if the issue seems display-related, and whether you're using any browser extensions that might interfere. Environment-specific bugs often only occur under certain configurations, and these details help developers test in the right environment.

🐛 Bug Reproduction Tip

Try reproducing the bug in an incognito or private browsing window. If the issue doesn't occur in incognito mode, the problem might be related to browser extensions, cached data, or cookies rather than the platform itself. This information is valuable to include in your bug report as it helps developers narrow down the cause quickly.

Where to Submit Bug Reports

We offer several channels for reporting technical issues, each suited to different types of problems. For critical issues that prevent you from working or affect your account security, contact support immediately via phone or live chat for the fastest response. Examples include being locked out of your account, data loss, or payment processing failures. These require immediate attention rather than standard bug report processing.

For non-critical bugs, use our bug report submission form in the help center. This form prompts you for all necessary information and routes your report to the appropriate team. The structured format ensures you include all relevant details and allows us to track the report systematically through our bug management system.

Community forums are useful for discussing issues with other users and determining if others experience the same problem. Post in the technical issues section with a clear title describing the problem. Other users might suggest workarounds, and our community moderators can escalate genuine bugs to the development team. However, forums shouldn't be your only reporting method for serious issues—always submit an official report for bugs affecting your work.

For very technical users, we maintain a public issue tracker on GitHub for our open-source components and developer tools. If you're reporting an API bug or issue with open-source libraries we maintain, the GitHub issue tracker is the appropriate venue. Follow the issue template provided and include code samples demonstrating the problem.

Writing an Effective Bug Report

A well-written bug report makes fixing the issue faster and easier. Start with a clear, descriptive title that summarizes the problem in one line. Good examples: "File upload fails for files larger than 50MB on Chrome," or "Calendar view crashes when selecting dates in November 2024." Avoid vague titles like "Something is broken" or "Feature doesn't work."

In the description, provide context about what you were trying to accomplish when you encountered the bug. Explain the expected behavior—what should have happened—and the actual behavior—what actually happened instead. This contrast helps developers understand the gap between intent and reality. Include the step-by-step reproduction steps you documented earlier, numbered for clarity. Anyone should be able to follow your steps and recreate the same issue.

Attach any relevant screenshots, screen recordings, or log files. For visual bugs, annotate screenshots with arrows or circles highlighting the problem area. For crashes or errors, include console logs if you're comfortable accessing browser developer tools—these logs contain technical details that are invaluable for developers. Many modern browsers let you save console output, and knowing how to capture this information makes you a bug-reporting superstar.

Specify the impact and severity from your perspective. Is this a minor annoyance, a significant workflow disruption, or a complete blocker preventing you from working? While our team ultimately determines priority based on multiple factors, your assessment of impact helps us understand how urgently this affects users. Explain any workarounds you've found—even if they're inconvenient, they help other users with the same issue while a fix is being developed.

Bug Report Priority Levels

Understanding how we prioritize bugs can set appropriate expectations for resolution timeframes. Critical bugs prevent primary functionality from working, cause data loss or corruption, create security vulnerabilities, or affect large numbers of users. These receive immediate attention, often with emergency patches or hotfixes deployed within hours or days.

High priority bugs significantly impact important features but have workarounds, or affect a moderate number of users. These are scheduled for the next release cycle, typically addressed within 1-2 weeks. Medium priority bugs cause inconvenience but don't prevent work, have readily available workarounds, or affect less commonly used features. These are scheduled based on development capacity, usually within 4-8 weeks.

Low priority bugs include cosmetic issues, minor text errors, or problems in rarely-used edge cases. These are fixed when resources permit, often bundled with other work in the same area of the application. While low priority doesn't mean unimportant, it does mean the issue isn't preventing anyone from accomplishing their work.

Following Up on Your Report

After submitting a bug report, you'll receive a confirmation email with a tracking number. Save this number for reference. You can check the status of your report by logging into your support account or searching for the tracking number. Status updates show where your report is in the review process—whether it's been acknowledged, reproduced, assigned to developers, or resolved.

If developers need additional information, they'll contact you via email. Respond promptly to these requests—bug fixes can stall when developers are waiting for clarification. If you discover new information or additional reproduction steps after submitting your report, add that information by replying to the confirmation email or updating the ticket in your support account.

When a fix is deployed, you'll typically receive notification. The notification includes which release version contains the fix and when it will be available. For web-based platforms, fixes are usually available immediately after deployment. For mobile apps, you'll need to update to the latest version from your app store. Test the fix when it's released and let us know if the issue persists—occasionally fixes don't cover all scenarios, and follow-up is needed.

Security Vulnerabilities

If you discover a security vulnerability—such as a way to access other users' data, bypass authentication, or execute malicious code—do not report it through normal channels. Security issues require confidential handling to protect all users while a fix is developed. Use our dedicated security reporting email address, [e-mail], to report vulnerabilities directly to our security team.

Include all relevant technical details about the vulnerability: the affected URLs or API endpoints, step-by-step exploitation instructions, proof of concept code if applicable, and the potential impact of the vulnerability. Do not publicly disclose security vulnerabilities before we've had time to fix them. We aim to acknowledge security reports within 24 hours and provide status updates throughout the remediation process. We also maintain a responsible disclosure policy and, where appropriate, credit researchers who report vulnerabilities.

Feature Requests vs. Bug Reports

If something is missing that you wish existed, that's a feature request, not a bug. We love hearing ideas for new features and improvements, but they follow a different process than bug reports. Submit feature requests through our product feedback portal rather than the bug reporting system. This ensures your ideas reach our product team who evaluates and plans new features.

Good feature requests explain the problem you're trying to solve or the use case you're trying to support, not just describing a specific solution. The more context you provide about why you need something, the better our product team can understand and potentially address the underlying need—sometimes in ways different from what you initially imagined.

After Reporting: Managing Expectations

Not all bugs get fixed immediately, and understanding why helps manage expectations. Some bugs are extremely complex, touching many parts of the system and requiring extensive testing before fixes can be deployed safely. Others might affect very few users, making them lower priority than issues impacting thousands. Resource constraints mean development teams must constantly prioritize what to work on, balancing bug fixes against new feature development and infrastructure improvements.

Sometimes bug fixes are delayed because they're symptoms of larger architectural issues that require more fundamental changes. A quick fix might be possible, but the team might opt to address the root cause properly rather than applying a temporary patch that could cause other problems. We appreciate your patience and understanding as we work through our development backlog. Your bug reports are valuable, and while not every issue can be fixed immediately, every report is reviewed and considered.