If something breaks and you're not sure how to explain it technically — that's fine. Riterly's bug reporting is designed specifically for that situation. You don't need to know what caused the problem, which browser version you're running, or what error code appeared in the background. The system captures all of that automatically. Your only job is to describe what happened in plain language.
What Bug Reporting Is
Bug reporting in Riterly is an in-app form that lets you flag problems directly from any screen, without technical knowledge, and without leaving the product to send an email.
When you submit a report, an AI translates your plain-language description into a structured bug report and files it automatically in the Riterly's system. The technical context — browser version, error codes, system state — is captured by the system at the moment you submit. You don't need to include any of it manually.
The form exists because the most common reason bugs go unreported isn't that users don't notice them — it's that the barrier between noticing and reporting feels too high. This removes that barrier.
How to Find It and What the Form Contains
The bug report button is in the bottom of the left sidebar on every screen. It's a small bug icon labelled Report a bug. Clicking it opens the bug report modal.
The modal has two fields:
- "What happened?" — required. This is a plain-language text field where you describe what you were doing and what went wrong.
- Screenshot upload — optional. Accepts PNG or JPG files up to 5 MB. Click the upload area or drag and drop a file directly onto it.
That's the entire form. No dropdowns, no severity ratings, no technical fields to fill in.
What to Write in "What happened?"
Write what you were trying to do and what the product did instead. You don't need to diagnose the cause or use technical language. A clear, honest description of the sequence of events is enough.
These are examples of the kind of descriptions that work well:
- "I clicked Generate outline on my post and it said something went wrong. The post is stuck in Outline Review now."
- "I uploaded a writing sample in the Voice Workshop and got an error about a virus even though the file is a text document I wrote."
- "The draft came back blank. Just an empty card with no text."
- "I changed my profile colour and the page refreshed but it went back to the old colour."
None of those descriptions include error codes, browser versions, or technical terminology. They work because they tell the system what state the product was in, what action triggered the problem, and what the result was. That's all the AI needs to build a structured, actionable report.
If you have a screenshot that shows the problem — an error message, a blank screen, a visual layout issue — include it. Screenshots help significantly for anything visual. For functional problems, the text description alone is usually sufficient.
What Happens After You Submit
After you click Submit report, the form shows a spinner. Processing takes about five to ten seconds.
During that time, the system does three things:
- The AI reads your plain-language description and translates it into a structured bug report — with a title, steps to reproduce, observed behaviour, and expected behaviour.
- That report is filed automatically as a GitHub issue in the Riterly repository.
- A reference number is returned to you in the success message — for example,
#42.
That reference number corresponds to a real GitHub issue. It is tracked and prioritised by the development team. During beta, reports go directly into the development queue.
Do not close the modal while the spinner is active. If you close it mid-process, the submission may not complete. Wait for the success message before dismissing the form.
What to Know About Edge Cases and Limits
If the submission fails
If something goes wrong during submission, the form returns to its editable state with an error message. Your description is preserved — you won't need to retype it. Try submitting again. If repeated attempts fail, note what you were trying to report and contact the Riterly admin directly.
The rate limit
There is a limit of five submissions per hour per account. This is a technical measure to prevent the issue queue from being flooded. Under normal use, you will never reach it. If you do, wait until the hour resets before submitting again.
Duplicate reports
If you suspect someone else has already reported the same bug, submit anyway. Duplicate reports are consolidated rather than creating separate issues, and the volume of reports on a given issue signals how widespread the problem is. A bug reported by ten people independently gets prioritised differently than one reported by one. Submitting when you're unsure is always the right call.
Screenshots and security
Before any screenshot is processed, it goes through a security scan. Files flagged as infected are rejected. Files that pass the scan are processed and then discarded — they are not stored anywhere in the Riterly system.
If repeated submission failures prevent you from filing a report through the form, or if you can't access the left sidebar at all, contact the Riterly admin directly. Include your reference number if you received one before the failure occurred.