Uptime tells you the server answered. It does not tell you that Pay now threw, that the password reset never arrived, or that the payment script failed in one city and nowhere else. Acumen Logs walks those journeys in a real Chromium browser, on a schedule, and keeps the screenshot, the video, the console, and the request.
No credit card. The free plan includes one browser monitor, video recordings, email alerts, and a status page.
An uptime monitor asks whether a URL responded. Synthetic testing asks whether a person can finish the job. Acumen Logs runs both. The journey is what catches a broken button, a silent script error, or a gateway that loads and then refuses the charge.
GET / returns 200 in 180ms from every region you check.
Pay now throws before an order exists. The storefront is healthy. The sale is not.
The login page is reachable and the certificate is valid.
The password reset never lands in the test inbox, so the account cannot be recovered.
Every probe location can open the homepage.
The same checkout fails only from Frankfurt, because a payment script was blocked at the edge.
Write what a customer does in one sentence. The AI opens your site, finds the right links, fields, and buttons, and hands you a finished journey with a screenshot of every step. What used to take 10 to 20 minutes of clicking and selectors now takes seconds.
6 steps and 6 screenshots, built in seconds
Save journeyEach execution opens Chromium, follows the steps you defined, and stores enough of the session to debug the failure without asking a customer what they saw.
The journey runs in a real browser on the interval you set, from every minute to once a day depending on the plan. The same test can also be triggered on demand, or from a pipeline, without waiting for the schedule.
Pick the device when you create the test. Acumen Logs sets the viewport and the user agent, so a layout that only breaks on a phone is a failed step, not a guess.
Login, search, cart, shipping, payment, confirmation. Each step records success or failure. Conditional steps branch on whether an element is visible, so a cookie banner or an optional upsell does not fail a healthy run.
Every batch keeps stills and a recording. You see the screen the browser saw at the broken step: the empty state, the spinner that never resolved, the error the customer would have met.
JavaScript errors stay attached to the run. You can fail the journey when the console reports an error, and read the message in place instead of reproducing it by hand.
Filter by type and status: document, script, stylesheet, image, font, fetch. A single 500 on the payment call is visible even when the HTML around it returned 200.
Mark a run failed on JavaScript errors, on status budgets (one 500, or three 404s, for example), or when an expected string never appears. Ignore third-party hosts when only your domain should page anyone.
Performance, accessibility, best practices, and SEO are scored beside the functional result. A journey can pass and still show that the checkout got slow.
You do not need a browser-automation script to put a monitor on checkout. Teams that want the journey in CI can trigger the same test from GitHub Actions.
The Chrome extension watches you click through your live site and turns that path into steps. Open the site, press record, and walk the journey the way a customer would.
The no-code builder is where you add, reorder, and set checks: a startup URL, a device, a string that must appear, a condition on an element that is only sometimes there. A base-domain variable points the same steps at staging, a preview, or production.
AI journey generation drafts the steps from a sentence: sign in as a returning customer, add the wool coat, and stop on the order confirmation. Review the draft, then schedule it like any other monitor.
The GitHub Action starts a run from a workflow. Override the startup URL for staging, choose a region, wait for the result, and fail the job when the journey fails — or when warnings should be treated as failures. Keep the run URL in secrets.
Read the GitHub Action guide →The Acumen Logs Synthetic Test Recorder connects directly to your active browser tab. Open your web app or store, press record, and click through critical user journeys. The extension automatically maps resilient CSS & semantic selectors as synthetic test steps.
Tracks navigation through top-level menus and category links.
Locates product cards, modals, or variants using semantic text.
Records form fields (email, address) with variable test data.
Triggers submission and asserts the subsequent confirmation redirect.
The recorder interacts directly with standard DOM elements in any browser tab. Test live web apps, SPAs, and checkouts without installing tracking tags or custom dependencies.
Frontends frequently update class names and IDs. The recorder uses smart element hierarchy and semantic identifiers so design updates won't break your test suite.
Run multi-step tests across staging sandboxes or test gateways. Acumen Logs flags automated headers so scheduled test runs never contaminate your production analytics.
One checkout, checked from four cities. London, Ohio, and Singapore complete the purchase. Frankfurt fails on the payment request. A homepage uptime check would still be green in all four.
All five steps passed. No alert.
Payment returned 502. The other regions passed in the same minute.
All five steps passed. Payment authorized in under a second.
The purchase completed. Payment took 4.8s, over the sample warning line.
A step slower than 3 seconds is marked as a warning. You decide whether a warning sends an alert.
The run saves the screenshot and the video for this step, with the console error and the request log.
A journey that clicks through a live site needs limits. A journey that signs someone up is not finished until the message shows up.
Synthetic testing is the layer you add when a green homepage is not the same thing as a working product.
Smoke the release. The GitHub Action runs the journey against the URL you pass in, and the workflow can stop when the run does not pass. Production keeps its own schedule, so a regression that slips past CI is still caught later that night.
Cart, shipping, and the gateway are one journey. Run it on a short interval from more than one region. A 502 from the payment host in a single city is a revenue incident. The homepage check will not say so.
One project per client, a browser monitor on the flow that client sells through, and a status page for the people who ask if the site is down. The WHMCS module is there when monitoring is part of what you resell. SSL and domain checks sit beside the journey.
“Really easy setup process for user journey based synthetic monitoring, and all the reporting options we needed.”
Phil’s team uses synthetic monitoring and uptime monitoring.
There is no agent to install on your servers. Most teams have the first monitor running in about a minute.
“Checkout — production” ages better than “Test 4.” Choose the project, the startup URL, and desktop, mobile, or tablet. Add a base domain if the same steps should run against more than one environment.
Turn the schedule on when the steps are trustworthy. Revenue paths deserve a short interval; quieter journeys can run less often. Plans cover frequencies from every minute to once a day, and a pipeline can start a run between those ticks.
JavaScript errors, HTTP status budgets, a missing confirmation string. Then point the alert at a channel someone reads: Slack, Microsoft Teams, email, desktop, SMS, or a webhook into the pager or the ticket queue. Send a test alert before you trust it. Set a minimum fail count so one stray 404 does not wake anyone.
A token is 30 seconds of browser-test time. No credit card to start, and you can cancel any time.
Solo at $5 adds custom schedules and 150 tokens. Pro adds CI/CD and 6,000 tokens. Both are on the pricing page.
See every plan →Uptime checks whether a URL responds. Synthetic testing drives Chromium through a multi-step flow and fails when the flow fails: a form that submits nowhere, a script error, a payment request that returns 500, a confirmation string that never appears. Use uptime for reachability. Use a journey for the work the page is supposed to do.
Install the Chrome recorder, open your published site, and click through the journey. The extension turns those actions into steps. It remembers the control by what it is and where it sits, so a class name change on the next publish does not by itself break the test. After a real redesign, open the next run and adjust the step that no longer matches.
Chrome recorder →No. Record with the Chrome extension, assemble steps in the builder, or describe the journey in plain language and let Acumen Logs draft it. You can still start runs from GitHub Actions and the API when you want them in a pipeline.
Steps follow the journey you record or describe, and conditional branches cover elements that are only sometimes on the page. Acumen Logs matches controls by what they are for — Submit order, Add to cart — so a class-name change does not retire the test. After a real redesign, open the next run and adjust the step that no longer matches.
Desktop, mobile, and tablet, each with its viewport and user agent. Run from locations such as London, Frankfurt, Ohio, and Singapore, on their own or together, so a regional CDN or payments failure does not hide inside a single global check.
Yes. Every monitor includes a test inbox for confirmation mail, password resets, and other messages the journey has to open before it can continue. If the message does not arrive, the step fails.
Yes. Allowlist domains and addresses, block noisy third parties, and fail the run when the page requests a host outside the list. You can also ignore non-domain errors so a tracking pixel does not count as your outage.
The free plan needs no credit card: 10 uptime, SSL, and WHOIS checks, 30 synthetic tokens, screenshots, email alerts, and a status page. Paid plans start at $5 a month. You can change or cancel from the account, and the plan you have paid for stays in place until the end of that period.
See pricing →The GitHub Action triggers a synthetic run from a workflow. You can override the start URL, choose a location, wait for the result, and fail the job when the journey fails or when warnings should be hard failures. The action returns the run id, pass or fail, and response counts for later steps.
Read the action guide →Instant checks, core monitoring products, and engineering resources.
Create complete synthetic journeys from a simple prompt.
Explore builder →Start with one monitor. When the step fails, you will have the recording, the console line, and the request — before a customer has to write in.
