Privacy Policy

Effective date: 12 September 2026Last updated: 30 October 2026

Beyond Site is published by AstralApps Ltd (“we”, “us”, “our”). This policy explains what information the Beyond Site mobile application (“the App”) processes, why, and the choices available to you. Read the short version first, then the detail below it.

1. Information the App processes

Beyond Site stores the following locally on your device. Apart from the diagnostic records listed in section 4, none of it is uploaded, and we have no way to read it.

Websites you monitor

• Domain names, URLs, and display names you add
• Monitoring status, response codes, and response times you generate
• SSL/TLS certificate metadata (issuer, expiry date, subject)
• Deep-scan results (DNS records, TCP port state, TLS configuration, HTTP security headers, and derived risk findings)

Alert configuration

• Alert thresholds and their severity levels
• Alert history, including the last alert level sent for each site

App preferences

• Refresh intervals, theme and colour choice, display settings, downtime schedules and notes, your backup schedule, and feature toggles

Backups you make

• A backup is a single .appbackup file holding your sites, categories, settings and preferences. It is written where you choose: a place you pick in your device’s file picker, the App’s own folder on your device, or — for scheduled backups on iPhone and iPad, only if you choose it — the Beyond Site folder in your own iCloud Drive. Section 2 explains what that means.
• If you password-protect scheduled backups, the password is held in the platform’s secure credential store (the iOS Keychain or the Android Keystore) so backups can run while you are not using the App. It never leaves your device.

2. Where your data is stored

• App data is stored in the App’s private sandbox on your device, using the device’s local database and preferences storage.
• AstralApps operates no cloud storage, cloud backup or cloud sync for the App. The sites you monitor, your email settings, and your alert configuration are never copied to a server of ours. The App does send us the diagnostic records described in section 4, and that is the only thing it sends us.
• We have no ability to access, read, or recover data stored on your device, or in any backup you make, and we cannot restore it for you.

• A backup you save by hand goes wherever you choose in your device’s file picker. If that is iCloud Drive, Google Drive or another storage service you use, the file is held by that service under its own privacy policy, in your account — again, not by us.
• If your device backs up to iCloud (iPhone and iPad) or to your Google Account (Android), that backup may include App data. It is created and controlled by Apple or Google under their own privacy policies, not by us.

3. Network activity

The App contacts the internet only for the purposes below. This is a complete list of the outbound connections the App can make.

Website and server checks (the core function)

• The App connects directly from your device to the websites you ask it to monitor, to measure availability, response time, TLS configuration, and certificate validity.
• The target website’s operator will see your IP address in the same way it would for any browser visit. We are not an intermediary and do not see this traffic.

DNS resolution

• To resolve domain names and to retrieve DNS records such as SPF, DKIM, DMARC, and mail server configuration, the App may query public DNS-over-HTTPS resolvers. These may include Google Public DNS, Cloudflare, Quad9, OpenDNS, and Comodo.
• Only the domain name being looked up is transmitted. These providers handle that query under their own privacy policies.

Connectivity probe

• A request is made to a Google endpoint (generate_204) purely to determine whether your device currently has a working internet connection. No personal information is included in this request.

App diagnostics upload

• Roughly once an hour, while the App is running or its background monitor is on, the App sends the diagnostic records described in section 4 to our own server over HTTPS. This is the only connection the App makes to a server we operate.
• The App authenticates to that endpoint with app-wide credentials built into the App — not a login. There is no account and no per-user token, so what arrives is not tied to a person.
• The upload contains only the records listed in section 4, and never your mailbox password or SMTP settings.

Alerts

• Alerts are delivered as push notifications through your device’s operating system. The alert content passes through the notification service of your device platform, which applies its own privacy policy.
• Email alerts, when you switch them on, are sent directly from your device to the mail server you configured. The only information in the message is the alert itself — the site name, its status, and the certificate details that triggered it. Beyond Site operates no mail relay, so no copy of the message reaches us; the App keeps only the delivery log described in section 4.
• Your mailbox password (or app password) is held in the device’s secure credential store and is never transmitted anywhere except to the mail server you entered.

Domain registration lookups

• To warn you before a monitored domain’s registration expires, the App asks the registry that runs that domain’s ending (for example Verisign for .com) for its public registration record. Version 1.0.15 (build 81) and earlier send this request through rdap.org, a public service that forwards it to the right registry; later versions send it to the registry directly. Only the domain name is sent.

iCloud Drive (only if you choose it)

• If you choose iCloud Drive for scheduled backups, the App writes each backup into its folder in your iCloud Drive on the device, and iOS uploads it to your iCloud account. That transfer is between your device and Apple; nothing passes through a server of ours. The App also asks iOS whether iCloud Drive is turned on and whether each backup has finished uploading, so it can show you.

App store connection

• When the App starts, it checks with your device’s app store — the App Store on iPhone and iPad, Google Play on Android — whether you have a subscription. None is on sale yet. That check is made by Apple’s or Google’s own purchase software and handled under their privacy policies; nothing from it is sent to us.

Links you tap

• Tapping a support or company link opens your browser or email app. Those destinations apply their own privacy policies.

Payments

Beyond Site is currently free. During the launch period every feature, including unlimited monitored websites, is available at no charge, and there is nothing to buy.

• We do not receive, transmit, or store your card number, billing address, or any other payment details. The App cannot access them.
• The App currently has no checkout screen and takes no payment, so nothing in it can charge you.
• We plan to offer an optional paid plan in future (see the Terms and Conditions). We expect it to be sold through your app store, which would handle the payment. Before any subscription is offered, this policy will be updated to explain what information that involves.

4. App diagnostics and email logs

Beyond Site keeps a small record of how the App is behaving, so that faults can be found and fixed and the parts people rely on most can be made better. It is a record about the App, not about you. It is not linked to your account — there is no account — and it contains no way for us to work out who it came from.

What is sent

• Which screens you visit — the name of each screen the App opens, and whether you arrived, left, or returned. The App’s list of tracked screens is the App’s own screens only; it does not include the names or addresses of the sites you monitor.
• Which features you use — events such as a site being added or removed, a scan started or completed, a group scan or deep scan begun or finished, a CSV imported or exported, a backup exported (by hand or on a schedule) or restored, email settings saved, an email connection test run, a mail server connection tested, alerts switched on or off, a scheduled report sent, the App being launched or reset, and the App being opened to a screen. These events carry counts, durations, on/off choices, and outcomes only — for example, how many sites a refresh checked and how long it took, which alert bands have email switched on and how many recipients each has, the kind of connection security your mail settings use, or the App’s own short description of why a connection test failed. They never carry a site, a group name, an address, a file name, a server name, or anything else you typed.
• Whether background monitoring is running — once a day, a summary of the background checks: how many ran, how many failed, how many were skipped because the device was offline, how many sites they checked in total, and how long the slowest one took. When you open the App it also records how long ago the last background check ran and the check interval you chose, so we can tell when a phone has stopped giving the App time to run.
• Errors the App hits — for a failure anywhere in the App, including one it recovers from and tells you about on screen (a backup that could not be written, for example): the error message, the exception type, the source code location, the stack trace, and which feature it happened in. This is the App’s own fault information, and it is the only diagnostic material we receive automatically. Before an error is stored, the App removes from its message the addresses of the sites you monitor, your mail server’s name, and any web address, email address, or IP address it contains. Ordinary network failures, such as a site not answering or your connection dropping, are not recorded at all: they are the App doing its job, not a fault in it.
• Whether an alert email was delivered — the recipient address you configured (so if alerts go to your own address, that address is in this log), the subject line, the purpose (alert, test, report or other), and whether the send succeeded or the reason it failed. An alert’s subject line is the alert’s own text and names the site that triggered it, for example Certificate Error: example.com. The body of the email is never recorded, and neither are attachments or recipient display names. This is a delivery log, not a copy of the message.
• A device snapshot attached to each record: the platform (iOS, Android, Windows, macOS, or web), the operating system version and build, the App version and build number, the device manufacturer, and a product model identifier such as iPhone16,2 (on Android, the model name, such as Pixel 8). This is the hardware model — it is not your device name, so it cannot read “Jane’s iPhone” or “Jane’s Pixel”.
• A connection snapshot: whether you are online and the type of connection (Wi-Fi, mobile, ethernet, VPN, and so on). The App measures no latency and records no network name.
• The time of the record, and the platform the App is running on.

What is deliberately not sent

• The sites you monitor — their names, addresses, and results. When the App records that you opened a screen, it records the screen only. The detail it would otherwise carry — the site object behind it — is stripped before the record is written. The email delivery log above is the only record that can name a site.
• Your mailbox password and SMTP settings — server names, ports, and usernames — your sender address, your alert thresholds, and your backup contents. Nothing else from your mail and alert configuration is sent beyond what is listed above.
• Your screen size, language, approximate location, carrier, or IP address as measured by the App. We do not ask the App for any of them. The fields for these exist only for reports sent by the website (section 5), which is a different path.

When and how

• Nothing is uploaded until you have accepted the Terms and this Privacy Policy on the screen the App shows when it first opens. Records made before then wait on your device.
• Records are written to the App’s local database first and uploaded about once an hour, over HTTPS with certificate validation, in batches of 20.
• Repeated identical errors are collapsed, so a screen stuck in a failing loop does not flood the log. An error already reported is not re-sent for a short window.
• If the upload fails, the records stay on your device and are retried on the next pass. Nothing is lost, and the App never retries in a tight loop.
• Records are also deleted locally after 30 days, described in section 8.

This is a small amount of information about the App’s own behaviour, and it is the only thing the App sends to a server we run. It is not a third-party analytics or crash-reporting product: there is no Google Analytics, no Firebase, and no Crashlytics in the App. The records are written by our own code and sent to our own server, and we use them only to find defects, fix them, and understand which parts of the App are worth improving. We do not use them for advertising, we do not build profiles from them, and we do not sell or share them.

5. This website and the contact form

Section 4 describes the diagnostics the App sends us. This section describes the parts of our operation that involve a server we control and that you reach through a browser: this website, its anonymous error and usage reporting, and the contact form on the Contact page.

What the contact form collects

• Your name, email address, and the message you type, plus the subject you choose from a fixed list.
• Your IP address, used only to rate-limit submissions and to identify abuse. We do not use it to identify you, and it is not used for profiling or advertising.
• The form deliberately does not collect your phone number, postal address, or any information about the sites you monitor in the app.

What happens to it

• Your message is delivered to us as an email and stored in our mailbox. We keep it only as long as needed to deal with your enquiry and to keep a record of the support we have provided, after which we delete it.
• We use it only to reply to you. We do not add you to a mailing list, and we do not sell or share it.
• Because the only thing we need to answer you is your email address, that is the only piece of the message we cannot delete on request while the enquiry is open.

Abuse prevention

To keep spam out of our inbox, submissions are checked automatically before they are sent. Depending on your connection and how the check is configured, this may involve:

• A rate limit, which counts submissions from your IP address over a rolling hour. Counters are temporary and are not linked to the content of your message.
• Turnstile, Cloudflare’s CAPTCHA service, if it is enabled on the form. Turnstile runs a challenge in your browser and sends Cloudflare a token that our server verifies. Cloudflare receives your IP address and browser characteristics as part of that check and handles them under its own privacy policy. No challenge is present if the widget is not displayed on the form.

Cookies and analytics on this site

• This website sets no advertising or tracking cookies. The Turnstile widget, when enabled, may set a functional cookie needed for the challenge to work.
• The site also keeps anonymous error and usage records of its own, described next. They involve no cookie, no device identifier, and no account, and they are not shared with any third party.

Website error and usage reporting

So that faults on this site can be found and fixed, our own server — the same one behind the contact form — records two kinds of anonymous report:

• Page views and key actions — which page was opened and which links or buttons were used. Only the page path is recorded, never the full web address, so a link you followed from somewhere else is not captured.
• Errors — the error message, the code location it came from, and the page it happened on, if the site or the contact form fails.

Each record also carries the technical details a web server receives with any request: your IP address, your browser and operating system, your language, your screen size, the connection quality your browser reports, and the time of the report. The IP address is recorded only so that abusive traffic can be rate-limited, and it is not used to identify you.

This reporting is not a third-party service such as Google Analytics, and no data from it is shared with anyone. It is part of the site rather than a widget you can decline, so it runs whenever a page is loaded. We use it only to see which pages are read and to fix faults, and we keep it only as long as it is useful for that.

Writing to us directly

You can always skip the form and email support@astralapps.com directly. Your mail then passes through our email provider, whose handling is governed by its own privacy policy.

6. What we do not do

We want to be unambiguous about this.

• We do not collect your name, phone number or postal address through the App, and there is no account to create.
• We do not sell or rent your data.
• We do not share your data with third parties for advertising.
• We do not use your data for tracking across apps or websites.
• We do not profile you or build behavioural advertising audiences.
• The App contains no advertising SDK, no third-party analytics or crash-reporting SDK, and no social login. The diagnostic records in section 4 are written by our own code and sent to our own server.

Because the App does not track you or use your data for advertising across other companies’ apps and websites, iOS does not display an App Tracking Transparency prompt, and on Android the App does not request or use the advertising ID.

7. Platform diagnostics and crash reports

• The App includes no third-party crash reporting service. Crashes and errors are recorded by our own code, as described in section 4.
• This website is separate: a fault in the site itself is recorded by our own server, described in section 5. That reporting is limited to the site and never touches the App or anything you store in it.
• Apple may collect crash logs, performance data, and diagnostic information through iOS and App Store Connect, including the iOS crash report that the operating system produces if the App closes unexpectedly. This is governed by your device settings and by Apple’s privacy policy, and is available to us only in aggregate or anonymised form.
• You can control this in iOS under Settings → Privacy & Security → Analytics & Improvements.
• On Android, Google may collect crash reports, “app not responding” reports and performance data, and show them to us in the Google Play Console, if you have chosen to share usage and diagnostics data with Google. This is governed by your device settings and by Google’s privacy policy, and reaches us without your name or account. You can control it in your device’s Google settings, usually under Settings → Google → Usage & diagnostics.
• If Apple or Google shares diagnostics with us, we use them only to identify and fix defects and improve reliability.

8. Data retention and deletion

Your App data lives on your device and is yours to remove. The diagnostic records described in section 4 are a separate, shorter-lived matter.

• Your monitoring data, settings, and email configuration are retained until you remove them.
• You can delete individual monitored sites and alert thresholds from within the App at any time.
• Deleting the App, or clearing the App’s storage, removes all locally stored App data. It also deletes the App’s cached upload credential, and the App then stops sending us anything at all.
• Deleting the App does not delete backup files kept outside it — a backup you saved with the file picker, or scheduled backups in your iCloud Drive. They are yours and stay in your own storage until you delete them, in the Files app, in iCloud Drive, or with Remove backups from iCloud on the Scheduled Backups screen. We cannot delete them for you.
• The App keeps its diagnostic records for 30 days and deletes older ones automatically. Because those records are not linked to you, there is no individual record to retrieve or erase — but you can stop further uploads at any time by deleting the App.
• Records that have already reached our server are kept only for as long as they are useful for diagnosing faults and improving the App, and are then deleted. For the most part they are counts and timestamps rather than a profile of any person. If you would like records from the email delivery log in section 4 removed, contact us using the details in section 12 and we will delete them.
• If you have questions about deletion, or want help understanding what we hold, contact us using the details in section 12.

9. Security

• App data is confined to the operating system’s App sandbox, protected by the device’s passcode, biometric, and encryption protections.
• All network requests made by the App use HTTPS/TLS.
• Backups, including scheduled backups saved to iCloud Drive, can be protected with a password; the file is then encrypted with AES-256 on your device before it is written.
• We practice data minimisation: the App stores only what a feature requires, and the diagnostic records described in section 4 contain only the fields listed there. The website likewise reports only the fields listed in section 5. The only information we hold centrally is those two record sets and whatever you choose to send us through the contact form.
• No method of electronic storage or transmission is perfectly secure. We recommend keeping your device updated and protected with a passcode.

10. Children’s privacy

Beyond Site is a professional monitoring tool. It is not directed to children, and we do not knowingly collect any information from children. The App requires no account, asks for no personal details, and its diagnostic records carry nothing that could identify a child. This website is likewise not directed to children, and the contact form should not be used by them; if we learn that a child has sent us a message, we will delete it.

11. Changes to this policy

We may update this policy as the App evolves. When we do, we will revise the “Last updated” date at the top of this page, and any change to what the App processes, or to where anything is sent, will be described in this policy itself rather than only in a release note.

Please review this page periodically.

12. Contact

Questions, concerns, or requests about this policy or your data:

• Email: support@astralapps.com
• Data controller: AstralApps Ltd, registered in England and Wales, company number 17537625
• Registered office: 13 Palmerston Street, Derby, DE23 6PE, England
• Website: https://www.astralapps.com

We aim to respond to privacy enquiries within a reasonable time.

If you are unhappy with how we have handled your data, you can complain to the Information Commissioner’s Office, the UK data protection regulator, at ico.org.uk.