Relvato

Add a heartbeat — Create a heartbeat for a job the user runs (cron job, backup script, scheduled task, CI job). Returns its ping URL: the job requests it when it succeeds (e.g. `your-job && curl -fsS -m 10 --retry 3 <pingUrl>`), and `<pingUrl>/fail` to report a failure (a POST body is kept with the ping). No ping within period + grace, or a failure, alerts the user at once; a new heartbeat waits for its first ping and never alerts before it. Adds the site's Heartbeats monitor with the first one. Plan limits per account: Free 2, Pro 20, Business 100, Agency 500.

List a site's heartbeats — A site's heartbeats — cron jobs, backups and scheduled tasks that check in by requesting their own URL: each one's state (new = waiting for its first ping, up, down), schedule (period + grace, in seconds), last ping, when the next is due at the latest, whether the plan covers it, recent missed or failed check-ins and pings, plus the account's heartbeats used / allowed. Full-access connections also get each ping URL (it's what the job requests; anyone with it can send pings).

Update a heartbeat — Rename a heartbeat, change its period or grace, or pause / resume it. Only the fields you pass change. Paused: pings are still recorded but nothing is judged or alerted (an open outage ends without a "back" alert); resumed, it waits for its next ping. Deleting a heartbeat stays in the dashboard.

Accept a structure change — The structure monitor found a page whose layout changed on purpose: adopt this run's structure as the new baseline for that page (pageKey), or for every changed page on the run (all: true). Undo with undo_structure_review.

Accept a visual change — The visual monitor found a page that changed on purpose (a redesign, new content): make this run's screenshot the new baseline for that page, device and browser. Undo with undo_visual_review. Only when the user confirms the change is intended.

Create a custom monitor — Describe in plain words what to verify on a page (e.g. "the Pro plan shows a price", "search for 'shoes' returns results") and Relvato's AI writes a monitor for it, in a minute or two. Follow it with get_check: status goes authoring → proposed (show the user its rationale and steps, then approve_custom_check) or needs-input (answer with reauthor_custom_check) or failed (with advice). Read-only by default; interactive: true lets it click and type (search, filters, forms). Plan-gated; counts toward the active-monitor limit.

Apply a run's proposed fix — WordPress sites: apply the one-click fix a run proposes (get_run proposedFix: e.g. clear a stuck maintenance file, turn indexing back on, roll back the plugin update that broke it) through the Relvato plugin, then re-run the monitor to confirm. Only that exact fix can be applied. Tell the user what it changes (proposedFix.why and undo) and get their go-ahead first. undo: true reverts the last fix Relvato applied on the site.

Approve a custom monitor — Approve a custom monitor's proposed recipe (status proposed) so it runs and alerts from now on. Show the user its rationale and steps first (get_check). A recipe in interactive mode clicks or types on the live site: approve it only after the user agrees, with ack: true.

Re-read the store — WordPress / WooCommerce: have Relvato read the store again (a product to buy, checkout type, guest checkout, currency) after the store changed. Runs in the background.

Cancel queued runs — Stop a site's runs that are queued but haven't started (after a big trigger_scan, or before maintenance). Cancelled runs can't be brought back: start them again with trigger_scan. The run that's already going finishes; nothing already recorded is deleted. Get the user's go-ahead first.

Dismiss a recommended monitor — Stop recommending a monitor for a site (list_checks marks recommendations), or bring every dismissed recommendation back with restoreAll.

Change a custom monitor — Give a custom monitor a new goal, page, name or mode. Its current recipe is dropped and the AI writes a new one, which needs approving again before the monitor runs.

Extend quarantine mode — Keep quarantine mode on for another 48 hours from now.

Flag a visual change as a problem — The AI review let a visual change pass, but it's actually broken: mark it a failure. The run counts as failed in Relvato and shows as needing attention (notifications, site health); no message is sent.

Get the WordPress activity log — WordPress sites: who did what — sign-ins and failed sign-ins (with the network, not the full address), accounts and roles, application passwords, plugin / theme / core updates, setting and file edits, PHP errors and failed emails — newest first, within the plan's history (7 to 365 days).

Get a monitor's settings — One monitor in full: on/off, when it runs (schedule, time zone, re-runs on WordPress updates, random extra runs, and whether the plan allows them), its own settings (the visual monitor's pages with their keys, masks, devices, browsers and threshold; the checkout's product, coupon, shipping and field answers; extra pages to scan; …), which settings sections update_check_settings accepts for it, the findings the user ignored, an AI-authored monitor's goal, status, question and recipe steps, and its latest run.

Get notifications — The dashboard's notifications: failing monitors, a disconnected or outdated WordPress plugin, a silent real-user beacon, domain and ownership problems, safe updates that need a look, paused Slack or webhook alerts, and billing.

Get a site's performance — A site's speed: the performance summary, lab Core Web Vitals, real visitors' LCP / INP / CLS (p75, last 7 days against the 28 before, per page type and device), what slows it (the elements, images and scripts behind slow visits) and the top fixes with steps.

Get quarantine mode — Quarantine mode (WordPress, paid plans): 48 hours of hourly security runs after a cleanup, with plugin updates paused. Whether it's available, on, until when, every change it saw (expected or not), which monitors it watches, the runs it would use, and past sessions.

Get a safe update's progress — Follow a safe update or deactivation: applying → verifying → passed, or reverted with the monitors that broke.

Get a site's health over time — How a site has been doing: the pass rate now and each of the last 30 days, the trend over 28, 90 or 182 days, each monitoring group's briefing (what needs attention, its likely cause and fix), and — on paid plans — uptime from Relvato's own probes (availability % and incidents over 30 days).

Get a site's settings — A site's Settings tab as values: what update_site_settings may change (name, request pacing, spacing between runs, firewall retry delay, flaky-monitor recovery streak, plugin rollback, counting Relvato's own visits in real-user data), what only the dashboard changes (browser identity, proxy, firewall allowlist token — never its value — GitHub, Google / Bing connections), the WordPress plugin's version, and the real-user beacon snippet.

Get status pages and client reports — Public status pages (title, public link, sites, on/off) and monthly client reports per site (on/off, how many recipients, last sent), plus the report branding. Never a report's private link or recipients' addresses. Edited in the dashboard's Agency page.

Get a site's WordPress updates — WordPress sites: the safe auto-update policy and its recent windows (what was updated, rolled back or skipped, and why), plugin versions held back after a rollback, safe updates or deactivations Relvato made and their outcome, and the hardening settings that are on.

Ignore a finding — Stop a finding (a warning on a run, by its key from get_run) from counting on this monitor: it stays on the run, marked ignored, but no longer alerts or fails later runs. Undo with unignore_finding. Only do this when the user says the finding is expected.

Ignore a structure change — Ignore specific element changes on a page from now on (signatures from get_run metrics.pages[].added / removed / countChanges[].sig), e.g. a widget that comes and goes. Undo with undo_structure_review.

Ignore a changed area — Ignore the area that changed on this comparison from now on (a clock, a rotating banner): it's added to the baseline's ignored regions. Undo with undo_visual_review. A mask (update_visual_monitor) is often the better fix.

Rewrite a custom monitor's recipe — Have the AI write a custom monitor's recipe again: answer its question (status needs-input) with `answer`, or retry after it failed or went stale. The monitor stops running until the new recipe is approved.

Report a false positive — Tell Relvato's team a run's result is wrong (it failed or warned about something that's fine). Sends the run's details and your note to Relvato's support team; it changes nothing on the run. To stop being told about a finding, use ignore_finding.

Ask Relvato AI for a fix — Ask Relvato's AI to suggest a fix for a run that failed or found a problem (the dashboard's "Suggest a fix"). It answers in a minute or two: read it as aiFix on get_run. Plan-gated. get_fix_prompt gives the same brief for you to reason with yourself, without waiting.

Resume webhook alerts — Turn webhook alerts back on after Relvato paused them for repeated failed deliveries (fix the endpoint first; send_test_alert checks it).

Send a test alert — Send a test alert on one channel (email, slack or webhook) to check it arrives. Slack and webhooks are on paid plans and must be set up in the dashboard.

Set up monitors for goals — The onboarding shortcut: pick what matters and Relvato adds the monitors that cover it on the current plan (plus uptime, SSL, errors, maintenance mode and structure). Goals: flows (checkout and sign-in), security, search, design, speed, domain, custom, ai.

Start quarantine mode — After a hack or a cleanup (WordPress, paid plans): run the security monitors every hour for 48 hours, pause plugin updates, and alert on every unexpected change. Uses runs (get_quarantine says how many). Stopping it early stays in the dashboard.

Safely update or deactivate a plugin — WordPress sites: for a vulnerable or outdated plugin a run found (get_run warnings with a plugin), update it (or deactivate it) through the Relvato plugin, re-run the monitors that were passing, and undo it automatically if any of them breaks. Counts as runs. Follow it with get_safe_update. Get the user's go-ahead first.

Undo a structure decision — Undo the last accept or ignore on a page of the structure monitor.

Undo a visual decision — Undo the last accept or ignore on this page, device and browser: the earlier baseline comes back.

Stop ignoring a finding — Make an ignored finding count again (get_check lists a monitor's ignored findings with their keys; get_run marks them on a run).

Change alert timing and severity — Change how often alerts are sent (instant and/or a daily or weekly digest), when the digest goes out, the minimum severity, and whether every run is emailed. Only the fields you pass change. Who gets alerts (the address, Slack, webhooks), muting sites or monitor types, and turning email alerts off stay in the dashboard.

Change a monitor's settings — Change a monitor's own settings. Each monitor takes only its sections (get_check lists them as editable.sections): checkout (checkout monitors), devices (flow and page monitors), errorScan, brokenLinks, aiOutput, browseUrl (storefront), shopUrl / productUrl (prices), dkimSelectors (email authentication), structurePages (structure drift), webVitalsDevices (Core Web Vitals). Every address must be a full URL on the site's own domain. A section you pass replaces that section; the rest stays. Turning it on or off and its schedule: update_check. The visual monitor: update_visual_monitor.

Change a site's settings — Change a site's operational settings. Only the fields you pass change. Browser identity, the proxy, the firewall token, GitHub and search-engine connections, and deleting the site stay in the dashboard.

Change the visual monitor's pages — Edit the visual regression monitor: add pages (a built-in one by key, or a page of your own by its address on the site, e.g. "/pricing"; up to 10 of your own), rename or re-point a page of your own, change any page's masks (CSS selectors painted over before comparing, for clocks, carousels, ads), remove pages, and set devices, browsers, full-page capture, the change threshold (percent) and the AI review. A page whose masks or address change gets a new baseline: its next run captures one for the user to approve. At most 40 screenshots a run (pages × devices × browsers). get_check lists the cur…

Verify the real-user beacon — Check that the real-user Web Vitals beacon is on the site (its homepage, or data already arriving). get_site_settings has the snippet to install.