Your checkout broke on Tuesday.
A customer told you on Thursday.

Rima is a browser testing tool that records what you do and repeats it. Instead of writing test code, you add the Rima extension to Chrome or Firefox and click through a flow in your own app the way a customer would: signing up, checking out, editing a record. Rima writes down every step as you go. It remembers each button and field in several ways at once, so a small change to your page usually will not break the saved test. From then on Rima can run that flow on its own servers, on whatever schedule you choose, or on your own machine through the rima command line tool. Every run in the cloud keeps screenshots, a video, and a step-by-step record of what the browser did, and results land in a dashboard the whole team can read. Rima exists so the people who know the product best can protect its important flows without waiting for an automation engineer.

Rima has a free plan and three paid plans, priced per person in your workspace. The Free plan costs $0, and signing up never asks for a card; you only reach a checkout if you pick a paid plan. Monthly plans are Starter at $5, Pro at $12, and Business at $25 per person. Yearly plans are Starter at $50, Pro at $120, and Business at $250 per person, which is twelve months for the price of ten and saves 17%. Paying more raises the limits rather than unlocking a different product: how many projects and tests you keep, how many cloud runs you get each month, how many run at once, and how long results stay available. The top plan also lets you claim your own Rima web address. A five-person team on the cheapest paid plan pays $25 a month, or $250 a year, and someone added mid-year is charged only for the time left. Full limits are on the pricing page.

No. Rima is built so you can create, run and look after browser tests without writing any code. You record a test by clicking through your own app in the browser extension, and you say what "working" means by pointing at it: this text has to appear, the page address has to be right, this element has to be there. Rima calls those checks validations. Scheduling, run history and the evidence from a failure all live in a web dashboard. Underneath, each recording becomes a real test script, which matters for two reasons. Your tests wait for the page to be ready instead of guessing at timing, and that is the main defence against tests that pass one day and fail the next for no real reason. And any developer on your team can read exactly what a test does. So developers are not shut out, they are just not required to get started.

Playwright, Cypress and Selenium are excellent testing frameworks, and they are all code: a developer writes the tests in a programming language, runs them on machines your team maintains, and looks after them like any other code. Rima is a different layer. Tests are recordings rather than code, they run on Rima's servers or on your own machine, and scheduling, video, evidence and shared team workspaces come with it instead of being assembled from parts. The Playwright comparison is the closest one, because Rima runs on Playwright underneath: your recordings become real Playwright scripts, so you get that engine's speed and its habit of waiting for the page rather than guessing, without writing the code. If your team would rather hand-write tests, those frameworks are the better choice and we say so. Read the honest head-to-heads: Rima vs Playwright, Rima vs Cypress, and Rima vs Selenium.

Yes. Runs on Rima's servers cover anything reachable from the public internet, and for everything else Rima has two answers. The rima command line tool runs the same recorded tests from a machine inside your own network: a laptop, an office server, or a server you run yourself. Staging sites, internal tools and builds on localhost never have to be exposed publicly, and results still report back, so local runs sit in the same history as cloud ones. The other option is a temporary private route, which lets Rima's browser reach a private address through a connection you open from your side, so nothing has to be opened up to the internet. Choosing between them is mostly a policy question: the command line tool keeps all browser traffic inside your network, while the private route keeps the running in Rima's cloud. Both are documented on the local runner page and in the docs.

Evidence, not just a red X. Every Rima cloud run captures screenshots at the moment of failure, a video of the whole browser session, and a step-by-step record of what the browser did: what the page looked like at each point, and exactly which action failed. Runs live on a page you can share, so a developer can step through the detail while a product manager watches the video, and nobody has to reproduce the problem from someone's description. Scheduled runs can email a summary, so something that broke overnight is in your inbox before standup. Failures also name the check that did not hold, the exact text, address or element, which usually points straight at the change that caused it. And because the recorded steps are real user actions, "the checkout test failed at the payment step" reads like a bug report a person would write.