Privacy Policy

The short version

• SiteGuardian does not sell user data.
• SiteGuardian does not use any AI on your data. No large language model, no embedding model, no AI agent is invoked on anything you give us. The product is rules-based: code that runs probes against URLs and code that decides when to send an alert or a transactional email.
• We collect what we need to monitor the websites you ask us to monitor and to email you when something breaks.
• We share the minimum data with the third-party services that make SiteGuardian work: Stripe to bill you, a transactional email proxy to send alert and onboarding email, and the Polsia hosting platform that runs the database and the application.
• A few integrations run only when an environment variable is configured: a Meta conversion pixel (off by default; we will update this page before we turn it on) and a first-party Polsia analytics beacon (on only if the platform injects its slug at deploy time). Each is described below in plain English.
• You have the rights described by the GDPR (EU and UK), the CCPA (California), and equivalent local laws. The fastest way to exercise any of them is to email siteguardian-8@polsia.app.

This page is written in plain English and intentionally longer than that short version. If something is unclear, write to us and we will explain.

What data we collect

Account data

• Email address (used to log you in and to send you alerts).
• Password (stored hashed; we cannot read it).
• If you sign in with Google, the basic profile Google returns (your email and your name, if you have one in Google).
• The date you signed up, and the date you last logged in.

Monitoring data (URLs you add and the results of the checks against them)

• The URLs you ask SiteGuardian to watch, plus any sub-paths you have configured (form endpoints, checkout endpoints, and the free-URL-only watch you can opt into after running a `/audit`).
• Probe results. What time we checked, what response code we got, how long it took, the SSL certificate we observed, the page-weight we measured, the broken-link status we observed, the contact-form or checkout success we observed.
• Alert history. When we detected an "it's down" condition, when we sent the email, and the matching "it's back" condition.
• Configured alert integrations you have set up. Slack incoming webhooks, generic webhook URLs, recipient email addresses. The destination URL, the site it is attached to, and the last delivery result and timestamp, for retry logic and so your alert history is complete.

Pre-account and anonymous data

SiteGuardian is usable without an account in three places: the public URL audit, the free monitored URL intake, and the contact form.

• Public URL audit (/audit). You submit a URL. The audit runs eight rule-based probes (see "Automated processing" below) and persists a single AuditReport row tied to that URL (a random identifier you can share by link). Anyone with the link can view the report. We do not ask for your name or email to view a report.
• Audit "save this report" or "email me the PDF" capture. If you click either button on the audit page, we create an AuditLead row carrying the email address you entered, and we email the PDF link to that address.
• Free monitored URL. If on the audit page you click the option to keep watching the URL for you, we create a FreeMonitoredUrl row for the URL plus a Contact row for your email, and we start polling that URL on the cadence below. The same Contact row backs both pre-account and post-account onboarding.
• Waitlist. The waitlist page creates a WaitlistEntry row carrying your email and an optional referral code. Each click on your referral link creates a ReferralClick row (the IP address is hashed before storage), and each signup that comes through your link creates a ReferralConversion row.
• Contact form (/contact). You fill in a name, an email, and a message, and the request itself carries your IP address. The submission is forwarded immediately through the transactional email proxy to the operator inbox; it is not written to our database. A hidden `website` honeypot field rejects obvious bot submissions.

Cookies and local storage, summary

• Authentication cookies set by our auth provider, so you stay signed in across requests.
• A theme preference (light or dark) in local storage, set by next-themes so the site honours your pick on the next visit.
• A "cookies dismissed" flag in local storage so this banner does not reappear.
• Stripe cookies, but only on Stripe's hosted checkout page. We have no control over which cookies Stripe sets on their own pages; see our cookie notice for the full list.
• One first-party analytics beacon from the Polsia hosting platform, only if the platform injects its slug at deploy time (that flag is opt-in at the platform level, not per-visitor). That beacon stores a per-visitor UUID called polsia_vid in local storage and fires a one-pixel request per page load. No third-party domain is contacted; no third-party cookie is set.
• One third-party conversion pixel from Meta, only when the deploy-time env var NEXT_PUBLIC_META_PIXEL_ID is set. We do not currently set that env var, so this pixel is off in our current build. If we ever turn it on we will update this page first.

The full inventory lives in our cookie notice at /legal/cookies.

How we use the data

• To identify you and keep you signed in.
• To run the checks you have signed up for, on the cadence your plan allows. FreeMonitoredUrl rows are polled every fifteen minutes.
• To send you alert emails when something looks wrong on a URL, and the matching "back" email when it recovers.
• To send you a small, fixed sequence of onboarding emails, then a weekly digest, then a timed upgrade nudge if you are eligible. The schedule is declared in our deploy manifest (see the cron table in polsia.toml) and runs every evening at a fixed UTC time, never varies per recipient.
• To bill you. Stripe handles card capture; we store what plan you are on, the last four digits of your card, and your subscription status.
• To answer support questions you email to us.
• To improve the product, by looking at aggregated uptime stats and common failure modes. We do not use individual probe payloads or alert content for advertising, marketing optimisation, or to train any AI model.

AI and automated processing

We call this out explicitly because the words "we use AI" can now mean almost anything. Here is what SiteGuardian actually does, in three layers.

• No AI on your data. The ai capability module is explicitly not installed in this deployment. No large language model, no embedding model, no AI agent, no image-recognition model is invoked on any field of any row in any table. If someone offers you an "AI summary of your monitoring history," that is not us; we do not have that feature.
• No training of any AI model on your data. Not ours, not anyone else's.
• Rule-based automation we do run, with full disclosure.

- Eight probe kinds used by /audit and by your account. Run by ordinary code, not a model. Uptime (HTTP status), SSL certificate expiry, broken-link scan (regex over page HTML rather than a headless browser), contact-form probing (a synthetic form submission POSTed to the URL you asked us to check), checkout probing (a transactional HTTP check), page-speed measurement (timing and size), SEO hygiene (presence of noindex, canonical, robots and sitemap), and a basic accessibility scan (alt-text and label coverage). The contact-form and checkout probes POST synthetic payloads to the URL you asked us to check; the third-party site operator therefore sees the probe's IP address and a User-Agent identifying the probe. - The scheduled jobs that keep the system running. Declared in the polsia deploy manifest (polsia.toml). They cover uptime checks, SSL expiry checks, page-speed checks, broken-link scans, contact-form probes, checkout probes, free-URL polling, the four-email onboarding trough, the weekly pulse digest, the upgrade-nudge email, the lifetime-deal pitch, the billing-fulfillment sweeper, and the cold-outreach tick. Every scheduled job is a small Node script that reads its own rows from the database, does its work, and writes results back. - The pre-account and post-account email cadence. Each new signup goes through a fixed sequence: a welcome send plus a small set of timed nurture emails, then a weekly pulse, then an upgrade prompt if eligible. All emails are sent through the transactional email proxy; the proxy routes mail to the address on file and tracks delivery. There is no per-recipient copy variation, no "send a different message because we think you are a good lead" step. The schedule is fixed; the words are hand-written and reviewed. - Alert decision logic. The decision to send an "it's down" email, to retry a request, or to fire a Slack alert is a sequence of if-statements over your probe results, not a learned model.

• No automated decision with legal effect on you. Under Article 22 of the GDPR and equivalent rules, an automated decision with legal effect is one that materially affects a person's rights (for example, denying credit, refusing a job, terminating a contract). SiteGuardian does not make decisions of that kind. Refunds, credits, account suspensions, and pricing decisions are made by a human, with a human-readable reason available on request.

Third-party crawl transparency

Because the probes and schedulers above touch URLs you have signed up for, those URLs (and any third party hosting those URLs) see probe requests from our infrastructure. The third-party site operator sees:

• The probe IP address, which resolves to our hosting platform.
• A User-Agent that identifies the probe (for example, our broken-link scanner user-agent).
• A synthetic payload for the contact-form and checkout probes, identifiable as a probe rather than a real customer.

We do not crawl, scrape, or archive the sites you monitor; we make specific, repeated functional checks. If you operate a site that is being monitored by a SiteGuardian customer, you may see our probe IP in your access logs.

What we do not do

• We do not sell user data. That sentence is the rule, not a slogan.
• We do not run advertising networks and we do not build advertising profiles of our users.
• We do not set third-party advertising cookies by default. The Meta Pixel, if we turn it on in the future, will be flagged here in advance. The Polsia analytics beacon, if the platform injects its slug at deploy time, is opt-in at the platform level and is described above.
• We do not use your monitoring data to train any AI model. Ours or anyone else's.
• We do not invoke any AI on any field of any row of your data, full stop. See "AI and automated processing" above.

Cookies and similar tracking

Listed in detail in our cookie notice at /legal/cookies. Cross-reference, not duplicate, lives there; the summary in this policy is the same as the "Cookies and local storage, summary" subsection above.

• Strictly necessary cookies: better-auth session/state cookies and Stripe's cookies on its hosted checkout page. We have no control over which cookies Stripe sets on Stripe's own domain.
• Preferences stored in local storage only: theme, cookies-dismissed flag, the optional Polsia analytics UUID.
• Optional, currently off: the Meta Pixel.

Third-party services

These are the only third parties that touch your data. Each one sees the minimum it needs to do its job, none sells your data, and each has its own published privacy policy linked below.

• Stripe (privacy policy at https://stripe.com/privacy) is reached through Polsia's billing proxy. Stripe processes payments for our paid plans; it sees your card details, billing email, invoice amount, and the SiteGuardian invoice ID. Stripe sets its own cookies on its hosted checkout page; we have no control over those.
• Meta Platforms (privacy policy at https://www.facebook.com/policy.php) is conditional and currently off. If the deploy-time env var NEXT_PUBLIC_META_PIXEL_ID is set, Meta sees a single-pixel request and the standard Pixel cookies on every page, and tracks Lead and Purchase events on signup, on pricing-page CTA click, and on checkout-success. Any decision to opt in to the Pixel is made at the deploy level, and we update this page before flipping that flag.
• Slack (privacy policy at https://slack.com/trust/privacy) is visible to us only when you add a Slack incoming webhook as an alert destination. In that case, Slack sees the JSON payload we POST to your webhook URL. Treat that URL as you would treat any other credential.
• Polsia app platform (privacy policy at https://polsia.app/privacy) hosts the database, the Next.js application, and the cron runtime. The platform sees infrastructure-level logs and email metadata. It is contractually bound not to read your monitoring data.
• Polsia email proxy, at the URL referenced by the env var POLSIA_EMAIL_PROXY_URL, is what SiteGuardian uses to send every outbound email: alerts, onboarding, weekly digest, billing receipts, and contact-form submissions. The proxy sees your email address, the message subject, and the message body. The body may contain the URL we are alerting on and the failure detail.
• Hosting infrastructure. The site, the database, and the email proxy all run on managed cloud infrastructure; data is encrypted at rest; the operator is contractually bound not to read or use your data for any other purpose.

If we ever need to add another processor, we update this page before we switch it on.

Where data lives and international transfers

• The application database (Postgres) runs on managed infrastructure provided by the Polsia platform. Backups are stored alongside it. All data is encrypted at rest.
• The web application runs on the same platform's hosted-Next.js runtime.
• Email is relayed through the Polsia email proxy hosted in the operator's region. We do not currently commit to a specific country for primary storage.
• For the EU and UK GDPR position, we rely on the platform's standard contractual clauses (SCCs) plus the safeguards described in our cookie, infrastructure, and platform contracts, for any transfer of personal data out of the EEA.
• For California residents, we rely on the equivalent contract terms and the SOC 2 posture of the underlying providers.

If you would like more specific detail on where your data physically sits, write to siteguardian-8@polsia.app.

Your rights

If you are in the EU or UK, the GDPR gives you these rights. If you are a California resident, the CCPA and CPRA give you the equivalent rights. If you are in another jurisdiction with similar rules, those rules apply. To exercise any of them, email siteguardian-8@polsia.app. We respond within thirty days.

• Right of access. Request a copy of the personal data we hold on you. We will send you an export.
• Right to rectification. Correct inaccurate data. Most of it you can fix yourself from your dashboard. Anything else, email us.
• Right to erasure. Delete your account and most of what we have on you. What we keep is what we are required to keep for tax or fraud reasons (Stripe invoices, basic account history). See the retention section below for what survives deletion.
• Right to data portability. Receive your data in a portable format. Available as part of an export request.
• Right to restrict processing. Ask us to pause a specific kind of processing while a question is resolved.
• Right to object to processing. Including objection to any marketing-style processing on the basis of legitimate interest. Every transactional email we send has a one-click stop link.
• Right to withdraw consent. Anywhere we rely on consent (for example, the optional Polsia analytics beacon), you can withdraw at any time without affecting prior processing.
• Right to lodge a complaint with a supervisory authority. If you are unhappy with how we handled a request, you have the right to complain to the data-protection authority in your country. For EU residents, the European Data Protection Board at https://edpb.europa.eu/ lists each national authority. For UK residents, the Information Commissioner's Office at https://ico.org.uk/. For California residents, the Office of the Attorney General at https://oag.ca.gov/privacy. We would rather you tell us first so we can fix it, but the right is yours.
• Lawful basis for processing under GDPR Article 6. For most of the work we do on your data, the basis is performance of a contract under Article 6(1)(b): we process your data in order to give you the monitoring service you signed up for. For transactional alerts and onboarding mail, our basis is also legitimate interest under Article 6(1)(f), and you can object at any time. For data we are required to keep for tax or accounting reasons, our basis is legal obligation under Article 6(1)(c).
• No automated decisions with legal effect. See the AI and automated processing section above.

Children's privacy

SiteGuardian is a business tool. We do not knowingly collect data from anyone under thirteen years of age; we use the COPPA-thirteen threshold rather than a higher country-specific age so the rule is the same everywhere. If you are a parent or guardian and you have reason to believe your child has signed up, email siteguardian-8@polsia.app and we will close the account and delete what we have.

How long we hold data

The retention policy below mirrors what the code does today. A future change will add automatic per-plan pruning; until then this section is descriptive of current behaviour.

• Account and billing data. Kept for as long as your account is active, plus the period required by tax and accounting rules (typically seven years for invoices).
• Monitoring data (probe history, alert history). Persisted for as long as the account is active. The code does not currently auto-prune these rows by TTL; we keep them so your history page is complete. When you delete your account, the rows are deleted with it within thirty days; encrypted backups roll off within ninety days.
• Anonymous audit reports (AuditReport). Persisted indefinitely and shareable by anyone with the cuid link, because the audit page is unauthenticated. If you would like a specific report deleted, email the cuid to siteguardian-8@polsia.app and we will delete it.
• Audit-lead rows (AuditLead). Kept until you ask us to delete them, then deleted within thirty days.
• Free-monitored-URL rows and the associated Contact row. Treated like monitoring data while active. Deleted when you ask us to stop, when the email bounces persistently, or after ninety days of no engagement, whichever is first.
• Contact-form submissions. Not stored on our side. Forwarded immediately to the operator inbox via the email proxy, which retains them with the same retention as direct support email.
• Direct support email. Kept as long as it is useful, then deleted. We delete on request.
• Stripe invoices. Retained by Stripe under their own retention policy, which we have no control over.

Changes to this policy

When we update this privacy policy, we change the date at the top of this page. If the change is meaningful, specifically a new third-party processor, a new use of data, or anything that narrows a promise above, we email active paid customers a short summary before the change takes effect. Continuing to use SiteGuardian after that summary counts as acceptance of the new policy. If you do not agree, you can cancel before the change takes effect and (if eligible under our refund policy) receive a refund.

Contact

Privacy questions, data-access requests, or anything in this document you would like explained: siteguardian-8@polsia.app. We aim to reply within five business days.