Privacy Policy

CheckRoost is operated by Xplicit Coding LLC, a New York limited liability company doing business as Xplicit Tech Solutions, 6799 Main St, Cherry Creek, NY 14723. Questions about anything here go to [email protected]. Using CheckRoost is also governed by our Terms of Service.

Account data is who you are — your name, email address, organisation and authentication records. We decide how that is used, so we are the controller of it.

Monitoring data is what you have asked us to watch: the addresses of your sites and servers, the results of every check, and the contents of the pages those checks read. It also includes the people an organisation adds — its client logins, the subscribers to its status pages and the recipients of its reports. We process it on the organisation’s behalf to run the checks and show it the results; the organisation is responsible for it. We do not sell it, mine it, or train anything on it.

Your account details, so you can sign in and we know which organisation a monitor belongs to — and, if you turn on two-step sign-in, your authenticator’s registration, which Supabase Auth holds. The addresses you ask us to monitor, and any settings you attach to them.

A record of your agreement to the Terms of Service: your account, the email address it was verified with, the version, the time, and the organisations you belonged to then. It is kept after an account is closed, because it is the evidence of an agreement both sides made.

The results of every check — status, response time, and what a check found. For the checks that read a page, that includes the links and resources on it: broken links, mixed content and sitemap entries are stored so the next run can tell you what changed since the last one.

What the software you install reports. The WordPress plugin sends the site’s WordPress and PHP versions, its plugins and themes, settings that affect its health, and the names, sizes and dates of files that should not be public — never their contents. The server agent sends the server’s name, addresses and operating system, its load, memory and disks, pending updates, its installed packages and versions, the network ports it listens on, and its security settings. @checkroost/next sends the application’s runtime and the packages it ships.

What the accounts you connect report — Kinsta, GoDaddy, Cloudflare, GitHub, SpinupWP and the like: for example the sites a host runs, their plugins and backups, a domain’s renewal settings, a zone’s proxy settings and the server addresses behind it, and a repository’s list of dependencies. The keys you connect them with are stored encrypted.

Email addresses an organisation gives us to write to: its status-page subscribers (once they confirm), and the people its client reports go to.

What you post on the feedback board. Other organisations’ teams see your requests and comments without your name; our own staff see who posted them.

Operational records: when a check ran, when an incident opened and closed, when an alert was sent and to whom. Our servers also keep routine access logs — IP address, time, the address asked for and the browser — for a limited time, for security and troubleshooting.

The free public tools — the WHOIS and CMS lookups — store nothing you look up. Your IP address is used, in memory, only to limit how often you can ask.

We rely on these providers to deliver the service:

• Supabase — database and authentication (United States).
• DigitalOcean — application hosting (United States).
• Cloudflare — DNS and the proxy in front of this site (United States).
• Resend — delivery of the email we send: alerts, sign-in and invitation emails, client reports, and status-page subscriber notices (United States).
• Google Analytics — usage measurement, and only if you agree (United States). See Analytics and cookies for exactly what is and is not sent.
• Google PageSpeed Insights — loads and scores pages for the Lighthouse and Accessibility checks (United States). This is the one subprocessor that receives your monitored addresses: enabling either check on a site sends the addresses of the pages it scans to Google to be loaded and scored. It runs only on monitors where you have switched one on, and nowhere else.

Some lookups also leave our servers by design. Domain expiry is answered by the registry responsible for that domain, over RDAP, and asking it means telling it which domain we asked about. DNS checks query that domain’s own authoritative nameservers. The blocklist check asks blocklist operators, such as Spamhaus, about a site’s domain and its server’s address. To look for known vulnerabilities we send the names and versions of installed packages — never which site runs them — to OSV.dev, and the names of WordPress plugins to WordPress.org’s directory. These are inherent to the check: there is no way to ask about a domain, an address or a package without asking someone.

Everything else the vulnerability checks read — WordPress.org’s release list, Wordfence Intelligence, GitHub’s security advisories, CISA’s catalogue of exploited vulnerabilities, endoflife.date, the Node.js release index — we download; nothing about you or your sites is sent to them.

We will give notice before adding a subprocessor that handles monitoring data.

We ask first. Google Analytics is not loaded, and no analytics cookie is set, until you have said yes. Refusing is one click, the same as accepting, and the product works identically either way. If your browser sends “Do Not Track” or a Global Privacy Control signal we treat that as a no and do not ask at all.

You can change your mind at any time — — and withdrawing is as easy as giving it. We store your answer, the date you gave it and which version of this policy it applied to. If this section changes materially, we ask again.

We use Google Analytics to understand which parts of the product are used and where people get stuck. Advertising features are switched off, so the data is not used to build an advertising profile or to retarget you.

What is sent: the page you are on, how you arrived, approximate location from your IP address, device and browser, and the fact that an action such as importing monitors occurred — along with an opaque identifier for you and for your organisation, so we can tell whether a feature is used by one account or by many.

What is never sent: your name, your email address, the names or addresses of the sites you monitor, or anything you type into a filter or a search box. Addresses that identify a specific record are stripped before they leave your browser, so a monitor page is reported as the kind of page it is rather than as the monitor it is about.

The cookies we set

An analytics blocker will also prevent the collection, and nothing in the product depends on it working. Every cookie but the analytics ones is strictly necessary for the page that sets it.

Monitoring means making requests. Uptime fetches a page on the interval you set. The broken-links and mixed-content checks crawl the site, follow the links they find — including to other people’s sites, to see whether those links still work — and respect robots.txt. The sitemap check reads your sitemap and samples the URLs in it. On a server running our agent, the network ports the agent reports — other than SSH, the web and mail — are tried from the internet once a day, at the address the agent reports from, to see which can be reached. A connection is opened and closed; nothing is sent.

Requests name our monitor in their user agent, so they are recognisable in your logs — except the Lighthouse and Accessibility checks, whose pages are loaded by Google. Crawls hold a page budget and a time budget, and are rate limited, because the point is to watch a site rather than to load it.

Individual check results are kept for 14 days and then dropped. The hourly summaries built from them — which is what the charts read — and the timeline of changes are kept for 400 days. The daily availability record is kept for the life of the account, because a year of uptime history is the thing an uptime figure is made of.

Incidents and the alerts sent about them are kept for the life of the account. Delete a monitor and its checks, results, incidents and history go with it. A status-page subscriber who unsubscribes is deleted, not marked.

When an organisation’s account ends, its data is deleted from our live systems within 90 days, and from backups as they expire.

Every row belongs to an organisation, and the database enforces that rather than trusting the application to remember: the account the app connects as cannot read past those rules even if a query forgets to filter.

Traffic is encrypted in transit. The keys an organisation connects are encrypted in the database, with a key that is kept on the server and not in the database; the installation’s own credentials live in environment files on the server, not in this repository. Our plugin and agent releases are signed, and the signing key never touches our servers.

If we learn that someone has gained unauthorized access to personal information we hold, we will tell the people and organisations affected as the law requires. Report a vulnerability to [email protected].

Ask for a copy of your data, a correction, or deletion by writing to [email protected]. If your organisation was set up for you by someone else — an agency running CheckRoost on your behalf — they control the account, and asking them is faster than asking us. The same goes for a status-page subscription or a report you receive: the organisation that runs it decides, and every subscriber email carries a one-click unsubscribe.

CheckRoost is a tool for running websites. It is not for anyone under 18.

Material changes are posted here and, for anything affecting what we collect, announced by email to account holders. Changes to Analytics and cookies reset the consent question rather than relying on an answer given to an older version.