Kept for existing links. Monito runs plain-English end-to-end browser tests.
Where to file a bug, and what Monito copies into it
Monito is not a bug tracker. File the issue in the tracker your team already uses. Copy the run as markdown and paste it.
This page used to rank bug trackers and put Monito first. That ranking was ours, and it was wrong. Monito is not a tracker. It does not create a Jira issue, a Linear issue, or a GitHub issue.
Use the tracker the team already has. If you have none, GitHub Issues is enough for a repository you already work in, and Linear or Jira are the usual choices once more than one person is assigning work. This post does not score them. Their prices and features change, and a list written here would be stale the week it shipped.
What belongs in the ticket
A developer needs the steps, what you expected, what happened, and a link to the evidence. Monito's Copy as issue button, and monito run view <id> --issue-markdown, produce that markdown from the bug on the run. The fields are listed in the bug report template. You paste them.
The evidence behind the link is the run Monito made: screenshots, console output, and network requests recorded as method, URL, and status. It is not a recording of a production user, and it is not a HAR file.
The run's badge is still Passed, Failed, or Error. Copy a bug from a failed run. An error means the check could not verify the scenario. Do not file that as an app bug until you have read the cause.
Sign up to get a report you can copy. Prices are on /pricing.
Related posts
- Check localhost with monito check --local
- Have a coding agent run monito check
- Run the same checks on every deploy