Notification Guide

Every alert the app can send, written out in full, with what it means and what to do about it

Beyond Site sends 24 different notifications, and they are not all the same kind of thing. Some are telling you visitors cannot reach your site. Some are telling you a renewal is coming. Some are telling you about the app itself. This page lists every one of them as it actually appears on your phone, so you can match a message you have received to what it means — and know whether it needs you right now or can wait until morning.

Not sure how these look in practice? See a morning’s worth of alerts on a phone before working through the list.

Every alert opens with what changed, in a line such as Before: Up → Now: Down. When the app did not see the earlier state, the line is left out rather than guessed. Tapping any Beyond Site notification opens the app’s Notifications screen, where each alert is kept with its date and time.

There is a second channel too. If you connect a mailbox in Email Configuration, the same problems also arrive as email — with more detail, and to whoever you choose. Those messages are worded differently, so they are listed separately below.

Needs action now

Visitors are affected, or will be soon. Something is broken or about to break, and the fix is on your side.

Worth a look

Worth a look. Something changed that you may or may not have intended, or a deadline is approaching with room to spare.

Good news

Good news, or an early heads-up. Nothing to do — these are the ones that exist so the others never have to be urgent.

What a morning looks like

Four alerts from one incident, stacked the way they arrive on a lock screen

Alerts rarely arrive one at a time. A site going down produces a heads-up the moment it happens, a summary when the scheduled check catches up, and a recovery when it comes back — and if a certificate is what broke, a more detailed message arrives alongside the generic one. This is one real sequence for a single site. The stack below is in the order your phone shows it, newest at the top; the notes read the same four messages in the order they happened.

11:24
Beyond Site11:24

🟢 Site back online: example.com

Before: Down → Now: Up. The site is responding again — visitors can reach it.

Beyond Site09:52

⚠️ Monitoring finished — 2 of 8 need attention

Before: All good → Now: 2 sites down, 1 certificate expiring. Checked 8 sites at 09:52. 2 sites are down or unreachable. 1 certificate is close to expiry.

Beyond Site09:41

🔴 Certificate error: example.com

Before: Secure connection working → Now: Certificate error. Certificate has expired. Browsers are blocking visitors.

Beyond Site09:40

🔴 Site down: example.com

Before: Up → Now: Down. SSL handshake failed — visitors cannot reach it.

  1. 09:40

    The first sign of trouble. A check failed, so visitors are getting an error page instead of your site. The message carries what the check saw, here a failed SSL handshake, and its Before and Now confirm the site was up at the previous check.

  2. 09:41

    A second, more specific alert follows a minute later, and this is the one worth understanding. The first message said the secure connection failed; this one says why, and names the certificate rather than the server. When both appear for the same site, the certificate message is the actionable one.

  3. 09:52

    The scheduled check finishes and summarises everything it found across all eight sites, whether or not you watched any of the individual alerts. It is the sweep-up message: if you slept through the first two, this is the one that tells you how much needs attention.

  4. 11:24

    The site comes back. This closes the incident rather than starting a new one, so it is filed under green and can go to a different set of recipients. If a site recovers without you ever seeing a recovery alert, it means the outage is still ongoing.

This is one plausible run, not the only one. A certificate fault can appear on its own with no site-down alert preceding it, and the summary only appears if the background check is switched on. What does not change is the order: problem first, then context, then the all-clear.

Site availability

Sent when a site stops responding, and again when it starts responding. Beyond Site alerts on the transition rather than on every failed check, so a single blip does not fill your lock screen and a long outage does not nag you for its whole duration.

Needs action now

🔴 Site down: {domain}

Before: {previous status} → Now: Down. {cause} — visitors cannot reach it.

When it appears
The latest check could not reach the site at all: no response, a timeout, or a connection error.
What it means
The site is unreachable right now. This is the one you act on immediately — visitors are seeing an error page, a blank page or a browser timeout in the meantime. The cause is what the check itself saw, such as “Connection timed out” or “DNS resolution failed”; when no cause was identified the sentence reads “The site is not responding — visitors cannot reach it.”
What to do
Check the site yourself in a browser first. If it is genuinely down, look at your host or server, and check whether a deploy or DNS change went out just before the alert.
See a filled-in example
🔴 Site down: example.com

Before: Up → Now: Down. Connection timed out — visitors cannot reach it.
Good news

🟢 Site back online: {domain}

Before: Down → Now: Up. The site is responding again — visitors can reach it.

When it appears
A check after a failed one succeeds. Only sent if the site was previously reported down, so it also acts as the "all clear".
What it means
The outage is over. If you were in the middle of fixing something, this confirms it worked. If you were not, the outage resolved itself and is still worth a look at your logs.
What to do
Nothing, unless the outage was unexpected — in which case check the site logs for what happened and how long it lasted.
See a filled-in example
🟢 Site back online: example.com

Before: Down → Now: Up. The site is responding again — visitors can reach it.

SSL certificates

You set three warning thresholds in Alert Settings, Red, Orange and Green. One alert is sent as a certificate reaches each level, and nothing more while it stays in that level; another is sent when the certificate is renewed. The default bands are 90, 30 and 7 days, so you hear about a renewal three months out, again at a month, and again in the final week. Each alert names the level the certificate was in before and the one it is in now.

Needs action now

🔴 SSL certificate expired: {domain}

Before: {previous level and days left} → Now: Red, expired {days} days ago. Visitors see a security warning until it is renewed.

When it appears
A certificate reaches the Red level already past its expiry date — for example on a site you have just added. A certificate already reported at Red is not alerted again when the date passes, because its level has not changed.
What it means
Every visitor is being shown a full-page browser warning before they can reach the site. Most of them turn around. This is the most urgent alert the app sends, because the site is technically up while being effectively unusable.
What to do
Renew the certificate now. If your host handles renewals automatically, check that the renewal job has not failed.
See a filled-in example
🔴 SSL certificate expired: example.com

Before: No expiry warning → Now: Red, expired 2 days ago. Visitors see a security warning until it is renewed.
Needs action now

🔴 SSL certificate expiring: {domain}

Before: {previous level and days left} → Now: Red, {days} days left. Renew now, or visitors will see a security warning.

When it appears
The certificate has moved into your Red window (7 days by default) but has not yet expired.
What it means
Still time to act, but not much. Once the date passes, browsers start blocking visitors with a warning page.
What to do
Book or trigger the renewal today. A certificate issued today can take a few hours to appear on every server.
See a filled-in example
🔴 SSL certificate expiring: example.com

Before: Orange, 30 days left → Now: Red, 7 days left. Renew now, or visitors will see a security warning.
Worth a look

🟠 SSL certificate expiring soon: {domain}

Before: {previous level and days left} → Now: Orange, {days} days left. Book the renewal now so the site is never left insecure.

When it appears
The certificate has moved into your Orange window (30 days by default), outside the Red one.
What it means
Comfortable, but this is the window where renewals actually get arranged. Leaving it until the Red alert is how certificates lapse.
What to do
Put the renewal in the calendar, or start it now if your provider needs manual steps.
See a filled-in example
🟠 SSL certificate expiring soon: example.com

Before: Green, 90 days left → Now: Orange, 30 days left. Book the renewal now so the site is never left insecure.
Good news

🟢 SSL certificate renewal reminder: {domain}

Before: No expiry warning → Now: Green, {days} days left. An early reminder — nothing to do yet.

When it appears
The certificate has moved into your Green window (90 days by default), outside the Orange one.
What it means
An early heads-up, deliberately well ahead of the deadline. Nothing is wrong; it exists so the renewal never becomes urgent.
What to do
Nothing yet. It is the notice that lets every later alert stay a formality.
See a filled-in example
🟢 SSL certificate renewal reminder: example.com

Before: No expiry warning → Now: Green, 90 days left. An early reminder — nothing to do yet.
Good news

🟢 SSL certificate renewed: {domain}

Before: {previous level and days left} → Now: {level and days left}. The new certificate is in place — no action needed.

When it appears
The days left on a certificate go up after an expiry warning was sent, which can only mean a new certificate is in place. It replaces the earlier warning in your notification tray. A renewal you were never warned about passes quietly.
What it means
The all-clear for the earlier certificate warnings: the renewal worked and visitors are getting the new certificate.
What to do
Nothing. If you did not renew it yourself, your host or certificate provider did it for you.
See a filled-in example
🟢 SSL certificate renewed: example.com

Before: Red, 5 days left → Now: Green, 89 days left. The new certificate is in place — no action needed.
Needs action now

🔴 SSL certificate missing: {domain}

Before: {earlier certificate} → Now: No valid certificate. Visitors may see a security warning, or reach the site without encryption.

When it appears
The site answers, but no valid certificate could be read from it. The “before” is what the app saw last time, such as “Certificate valid, 45 days left”, or “Not checked before” for a site you have just added. It is sent once, not on every check.
What it means
The site is up but not properly secured. Browsers either warn visitors away or show the site without the padlock.
What to do
Check that a certificate is installed for this exact host name and that HTTPS is switched on at your host or CDN. A certificate lost in a migration or a server rebuild is the usual cause.
See a filled-in example
🔴 SSL certificate missing: example.com

Before: Certificate valid, 45 days left → Now: No valid certificate. Visitors may see a security warning, or reach the site without encryption.
Needs action now

🔴 Certificate error: {domain}

Before: Secure connection working → Now: Certificate error. {Detail}. Browsers are blocking visitors.

When it appears
The TLS handshake failed for a reason other than plain expiry: a name mismatch, an untrusted issuer, a revoked certificate, or an incomplete chain. This is a separate alert from expiry, and can fire on a certificate that is still in date.
What it means
Something about the certificate itself is broken. Unlike an expiry, this will never fix itself with time, and visitors are blocked right now. The Before/Now line appears only when the previous check had a working secure connection. Without it the body reads “Certificate problem — {detail}. Browsers are blocking visitors.”, or, where the cause cannot be identified, simply “The secure connection to this site is failing, so browsers are blocking visitors.”
What to do
Open the site and read the exact error your browser gives. A name mismatch usually means the wrong certificate was installed; an incomplete chain usually means an intermediate is missing on the server.
See a filled-in example
🔴 Certificate error: example.com

Before: Secure connection working → Now: Certificate error. Certificate has expired. Browsers are blocking visitors.

DNS changes

Beyond Site records your DNS records and compares each new reading against the last one. You choose which record types are watched in DNS Monitor settings, so you only hear about the ones that matter to you. Each alert lists the records before and now, with the changed values first, and you can have the same changes emailed by switching on DNS Email Alert.

Needs action now

🔴 {type} records changed: {domain}

Before: {old records} → Now: {new records}. Unexpected DNS changes can stop the site loading for visitors.

When it appears
A watched record type changed in a way that can affect reachability or mail: records added to a type that previously had none, all records removed, an MX record removed or replaced, a new SOA record, or DNSSEC validation being lost.
What it means
Traffic or mail may be going somewhere you did not intend. This is the shape a hijack, a registrar mistake or a half-finished migration takes.
What to do
Compare against what you expect and check who last touched the DNS. If you did not make the change, treat it as a possible compromise and rotate credentials once you have confirmed it.
See a filled-in example
🔴 MX records changed: example.com

Before: 10 mx1.example.com, 20 mx2.example.com → Now: 10 mx.newhost.net. Unexpected DNS changes can stop the site loading for visitors.
Worth a look

🟠 {type} records changed: {domain}

Before: {old records} → Now: {new records}.

When it appears
A watched record type changed in a way that does not affect reachability directly — a new A, AAAA, TXT, CNAME, CAA or SOA reading, or DNSSEC being newly enabled.
What it means
Informational. Often expected: a new verification TXT record, a CDN switch, a mail provider being added. Worth a glance rather than a panic.
What to do
Confirm it matches a change you asked for. If you do not recognise it, the likely culprits are a migration in progress, a third-party service adding a verification record, or a host changing IP addresses.
See a filled-in example
🟠 TXT records changed: example.com

Before: v=spf1 include:_spf.example.net ~all → Now: google-site-verification=abc123, v=spf1 include:_spf.example.net ~all.

Integrity monitoring

These five watch for changes that happen to a site that is otherwise working — the failures that availability checks alone never catch. Each one compares the current reading against a baseline recorded when the site was last known good, opens with the reading before and now, and reports a specific problem once rather than repeatedly.

Needs action now

🔴 Monitoring stalled: {domain}

Before: Checks succeeding → Now: No successful check for {duration}. No successful check has completed for {duration}. Alerts about this site may be out of date.

When it appears
Nothing has reached the server for several check intervals in a row — six intervals, with a floor of 30 minutes and a cap of 24 hours.
What it means
This is the app reporting on itself, not on your site. The site may well be fine; what is broken is your ability to see it. Every other alert depends on checks completing, so while this is showing you are effectively monitoring nothing.
What to do
Check the device or network running the monitor. A phone that is off, a laptop that is asleep, a lost connection or a captive-portal Wi-Fi network will all cause it — and the sites themselves are usually unaffected.
See a filled-in example
🔴 Monitoring stalled: example.com

Before: Checks succeeding → Now: No successful check for 5 hours. No successful check has completed for 5 hours. Alerts about this site may be out of date.
Worth a look

🟠 Security headers weakened: {domain}

Before: {protections} in place → Now: {what weakened}. {count} security protections that were present on the last clean check are now missing or weaker.

When it appears
A security header or cookie flag that was present and correct on the last clean check has disappeared or weakened. Only regressions count — a header that was already missing when the baseline was taken is not news.
What it means
Hardening that used to protect visitors is gone. This is what a careless deploy, a reverted config, or a compromised server looks like. It answers "did something get switched off?" rather than "is this site secure?".
What to do
Compare your server or CDN configuration against what it was. If nothing you did explains it, treat it as a possible intrusion and check your deploy and access logs.
See a filled-in example
🟠 Security headers weakened: example.com

Before: Strict-Transport-Security, X-Frame-Options in place → Now: Strict-Transport-Security missing, X-Frame-Options missing. 2 security protections that were present on the last clean check are now missing or weaker.
Worth a look

🟠 Page content changed: {domain}

Before: Unchanged page ({size}) → Now: Different content ({size}). The page changed after being stable for at least {checks} consecutive checks. Check that this change was intended.

When it appears
A page that had been byte-for-byte stable for three or more consecutive checks changes. Pages that change often — news, feeds, dashboards — never reach that stability, so they opt themselves out and never alert.
What it means
Either you changed the page, or someone else did. The fingerprint deliberately ignores scripts, styles, comments and generated tokens, so this is a real content change rather than a render timestamp.
What to do
Open the page and look at it. If the change was yours, nothing to do. If not, compare against your last known version and check how the files got modified.
See a filled-in example
🟠 Page content changed: example.com

Before: Unchanged page (48.2 KB) → Now: Different content (51.7 KB). The page changed after being stable for at least 3 consecutive checks. Check that this change was intended.
Worth a look

🟠 Site responding slowly: {domain}

Before: About {baseline} ms → Now: About {current} ms. The last {checks} checks took around {current}ms, well above the usual {baseline}ms.

When it appears
Three consecutive checks each took well over three times the site’s own normal response time, with an absolute floor of 3000ms so a fast site is never flagged for normal variation.
What it means
The site is up but consistently slower than it usually is. This is measured against the site’s own history rather than a fixed number, because 900ms is fine for a heavy site and poor for a small one. Slow sites lose visitors without ever looking down.
What to do
Check whether something changed: a deploy, a traffic spike, a cache that stopped working, a database that needs attention. The alert clears itself once the site recovers.
See a filled-in example
🟠 Site responding slowly: example.com

Before: About 780 ms → Now: About 4200 ms. The last 3 checks took around 4200ms, well above the usual 780ms.
Needs action now

🔴 Domain registration expired: {domain}

Before: {last warning} → Now: Expired. The domain registration has lapsed. The site will stop resolving once the registry removes it.

When it appears
The domain registration itself is past its renewal date. This is separate from the SSL certificate — a domain and its certificate expire on different dates and are renewed with different providers.
What it means
The registration behind the domain name has lapsed. This is a total outage that no hosting change can fix, and if the registration is released it can be bought by someone else. It is also the one failure here that is entirely preventable.
What to do
Renew the registration immediately, and contact your registrar if the renewal has already been rejected. Do not wait for the site to stop resolving — by then the grace period may be over.
See a filled-in example
🔴 Domain registration expired: example.com

Before: 3 days or fewer left → Now: Expired. The domain registration has lapsed. The site will stop resolving once the registry removes it.
Worth a look

🟠 Domain expires in {days} days: {domain}

Before: {last warning} → Now: {days} days left. The domain registration expires on {date}. Renew it to avoid losing the site.

When it appears
The registration is approaching renewal. It warns once per bucket — 30 days, then 14, 7, 3 and 1 day out — rather than every day.
What it means
A renewals reminder for the domain name itself. Note that this is a different date from the SSL certificate expiry, and the two are usually renewed in different places.
What to do
Renew it, or confirm that auto-renew is on with a valid payment method on file. If the domain is registered through a client or a previous web host, this is worth chasing early.
See a filled-in example
🟠 Domain expires in 14 days: example.com

Before: 30 days or fewer left → Now: 14 days left. The domain registration expires on 10 November 2026. Renew it to avoid losing the site.

Background check summary

A quiet notification posted after each scheduled background check finishes, so you can see that monitoring is running without opening the app. It is silent by design and uses its own low-priority channel, separate from your alert sound setting. When a check’s result differs from the previous one, it opens with the change, such as “Before: 2 sites down → Now: All good”. Turn it off in Alert Settings if you would rather routine checks said nothing.

Good news

✅ All {count} sites checked — all good

Last checked at {time}. No problems found.

When it appears
A scheduled background check completed and found nothing wrong on any site.
What it means
Monitoring is working and everything is healthy. If you had turned this off, its absence is also meaningful: it means no scheduled check has run.
What to do
Nothing. This is a reassurance, not a task.
See a filled-in example
✅ All 8 sites checked — all good

Before: 2 sites down → Now: All good. Last checked at 14:05. No problems found.
Worth a look

⚠️ Monitoring finished — {issues} of {total} need attention

Checked {total} sites at {time}. {issues} sites are down or unreachable. {certs} certificates are close to expiry.

When it appears
A scheduled background check completed and at least one site was down, unreachable, or at a certificate expiry the user’s own settings call urgent.
What it means
The count leads because that is the only part you need from a lock screen: how much needs you, out of how much was checked. A site you paused or that the plan cap parked is never checked, so it never inflates the count.
What to do
Open the app and work through the sites flagged. Individual alerts for each one will also be in your notifications.
See a filled-in example
⚠️ Monitoring finished — 2 of 8 need attention

Before: All good → Now: 2 sites down, 1 certificate expiring. Checked 8 sites at 14:05. 2 sites are down or unreachable. 1 certificate is close to expiry.

Device offline

Posted when the device running Beyond Site loses its internet connection, because at that moment the app stops watching your sites. It stays in the tray rather than dismissing, and re-alerts no more than once an hour while the device is still offline.

Worth a look

Beyond Site offline

Before: Online → Now: No internet connection. Monitoring will resume when connectivity returns. {sites} not being checked.

When it appears
The device has no internet connection and the offline warning is switched on (it is on by default).
What it means
Your sites are not being checked. The app is telling you that a gap in monitoring has opened, so an outage during this window will be noticed late.
What to do
Reconnect if you can. Otherwise the alert clears itself and monitoring resumes automatically the moment connectivity returns.
See a filled-in example
Beyond Site offline

Before: Online → Now: No internet connection. Monitoring will resume when connectivity returns. 8 sites are not being checked.
Worth a look

Beyond Site still offline

Before: Online until {time} → Now: Offline for {duration}. Monitoring will resume when connectivity returns. {sites} not being checked.

When it appears
The device has been offline for more than an hour and still is. The warning is refreshed rather than repeated, so it does not buzz hourly.
What it means
The same warning, with the outage timed. The first version says only that the connection has gone; this one says when it went and for how long, such as “Before: Online until 09:14 → Now: Offline for 2 hours 5 minutes”, so a glance tells you whether the gap is a blip or a morning-long problem.
What to do
The same as the first warning — there is nothing new to fix. It is worth knowing that nothing was checked while the device was offline, so an outage in that window surfaces only after you reconnect.
See a filled-in example
Beyond Site still offline

Before: Online until 09:14 → Now: Offline for 3 hours 20 minutes. Monitoring will resume when connectivity returns. 8 sites are not being checked.
Good news

Beyond Site offline warning cleared

The offline notice is removed automatically once a connection returns. Monitoring resumes on the next scheduled check; you can also tap refresh in the app bar to check every site immediately.

When it appears
The device reconnects, or the monitoring pause is lifted. Unlike every other alert on this page, nothing is posted to the notification tray.
What it means
The warning that was sitting in your tray is taken away, so its absence is the message. The monitoring gap is closed. Checks missed during the outage are not backfilled, so a site that broke while the device was offline is reported by the next check instead.
What to do
Nothing, though a manual refresh after a long outage is a quick way to confirm every site is still reachable.
What this looks like instead
No notification is posted. The “Beyond Site offline” warning leaves your notification tray, which is the only sign this has happened.

On the dashboard, the offline banner disappears and the next scheduled check runs normally.

Scheduled backups

Sent by Scheduled Backups in Backup & Restore, on a channel of its own so it can be silenced without touching your website alerts. A failure is always worth knowing about, because a backup that quietly stopped working is worse than none; a success is announced only if you turn that on. A newer result replaces the older one rather than stacking up.

Worth a look

Scheduled backup failed

{reason} It will try again later. Your earlier backups are untouched.

When it appears
A scheduled backup could not be made — for example the backup location was unavailable or the password for encrypted backups is missing from the device. Sent once per missed backup, not on every retry, and only while “If a scheduled backup fails” is on (it is on by default).
What it means
This backup was not made, but nothing was lost: the backups already kept are only ever removed after a new one has been saved and checked. “It will try again later” appears when another attempt is due within the hour.
What to do
Open Backup & Restore › Scheduled backups to see the reason, put right whatever it names, and use “Back up now with these settings” to check it works.
See a filled-in example
Scheduled backup failed

Sign in to iCloud and turn on iCloud Drive in Settings to back up there. It will try again later. Your earlier backups are untouched.
Good news

Scheduled backup complete

Saved to {location}. The oldest backup was removed to keep your limit.

When it appears
A scheduled backup was saved and checked, and “When a scheduled backup succeeds” is on. It is off by default, and posted quietly.
What it means
Your newest backup is in place. The second sentence appears only when an older scheduled backup was deleted to stay within the number you chose to keep.
What to do
Nothing. This is a reassurance, not a task.
See a filled-in example
Scheduled backup complete

Saved to iCloud Drive › Beyond Site › Scheduled Backups. The oldest backup was removed to keep your limit.

Email alerts

The same problems, delivered to a mailbox you own — with more detail, and to different people

Email alerts are a second delivery channel, not a copy of what appears on your phone. Turn them on and the alerts also arrive as ordinary email you can read on any device, forward to a colleague, or keep as a record of what happened and when.

The messages are not identical, and that is deliberate. An email has room for detail a notification banner cannot carry — the failure reason, the HTTP status, what to do about it, the technical error text. So the two channels carry the same events in different words, rather than the same words in two places. What they always share is the “What changed” block: the email shows the same Before and Now as the notification.

Email is also addressed differently. While notifications go to your one phone, each severity level has its own list of recipients, so routine green reminders can go to you and red failures can go to you and to whoever else needs to know.

Email alerts only send once you connect a mailbox in Email Configuration, in the toolkit alongside the other monitors. Until then nothing is emailed — the app is fully functional on notifications alone. There is no limit on how many alerts can be delivered, and a message that fails to send is never counted against you.

Email subjectSent forGoes toNotes
🔴 DOWN Alert: {domain} — {reason}A site becomes unreachableRed listAdds the detected cause to the subject — an HTTP status, a DNS failure, a timeout — so you can tell the fault apart without opening anything. The reason is dropped from the subject when the cause was not identified.
🟢 Recovery: {domain}A site that was down becomes reachable againGreen listFiled under green rather than red, so your recovery notices can go somewhere different from your failure notices.
{level}: {domain}An SSL certificate crosses one of your thresholdsThat level’s listThe level is spelled out in the subject — “Initial Alert: example.com”, “Warning Alert: …” or “Critical Alert: …”. Sent as a formatted email showing the expiry date and the days remaining, not just the banner text.
🟢 Certificate Renewed: {domain}A new certificate replaces one you were warned aboutGreen listFiled under green, like a recovery, so the all-clear can go to different people from the warnings. Includes the new expiry date and issuer.
🔴 Certificate Missing: {domain}A site answers without a valid certificateRed listSent once, alongside the push, with the certificate the app saw at the previous check.
🔴 Certificate Error: {domain}A certificate is broken rather than expiring — a name mismatch, bad chain, or untrusted issuerRed listThe most detailed message the app sends. It probes the site on plain HTTP to tell you whether the server is still running, and includes a short list of the usual causes with fixes.
Integrity findings — five separate subjects, all to the red listDespite the orange markers on the push versions, every integrity email is sent to the red list — that is the only per-level control the settings have. Each carries the recorded details and a “what to do” paragraph naming the likely real-world cause.
🔴 Monitoring Stalled: {domain}Monitoring has stopped producing results for a siteRed list
🟠 Security Headers Weakened: {domain}Browser-side security headers were removed or loosenedRed list
🟠 Page Content Changed: {domain}A page that had been stable changed substantiallyRed list
🟠 Site Responding Slowly: {domain}A site became persistently far slower than its own normalRed list
🔴 Domain Expiring: {domain}A domain registration is approaching its expiry dateRed list
🔴 Beyond Site offline: {sites} not being checkedThe device running the app loses its connectionRed listSent once per offline period rather than hourly. It opens with exactly the banner’s words, the same Before and Now and the same sentences, then explains what the gap means. This is the one alert whose meaning inverts the others: it is not saying your sites are down, it is saying the app can no longer see them.
🔴 {type} Records Changed: {domain}A watched DNS record changesDNS listOff by default: switch on DNS Email Alert in Alert Settings and give it its own recipients. One email per site per check lists every change with its records before and now, and says “DNS Records Changed” when several types changed. Orange instead of red when no change is significant.
NoneA scheduled background check finishes—No email. The routine summary stays on the phone, which is what keeps a mailbox from filling with “all good” messages.

Where each piece is switched on

A mailbox to send from

Email Configuration, in the toolkit. Add your server details and send yourself a test email before relying on it.

Who gets what

Alert Settings. Each severity level, green, orange and red, has its own on/off switch and its own recipient list.

Per site

The Alerts toggle on a site card silences every channel for that domain, push and email alike.

DNS changes

DNS Email Alert in Alert Settings: its own switch, off by default, and its own recipient list. It does not affect the DNS push notifications.

The offline warning

Its own switch in Alert Settings, on by default. Turning it off stops both the notification and the email.

Settings that change these alerts

Nothing above is fixed. These are the controls behind it

Alert thresholds

Three day-counts decide when each SSL certificate alert fires: Green, Orange and Red, defaulting to 90, 30 and 7 days. Any value from 0 to 100 works, as long as Red is not greater than Orange and Orange is not greater than Green. One alert is sent as a certificate reaches each level, and another when it is renewed. Tightening them makes the app noisier and safer; widening them makes it quieter.

Notification sound

A single switch for the alert sound. Turn it off and alerts still arrive — they appear in Notification Centre and the lock screen without making a noise. The background check summary is silent regardless, on its own channel, so it stays quiet either way.

Background check summary

Turns the after-each-check summary on or off. On, you get a quiet line confirming what the scheduled check found. Off, only problems notify you and routine passes stay silent — useful once you trust monitoring to run on its own.

Per-site Alerts toggle

Each site card has its own Alerts switch. Turning a site off silences every alert for that domain without changing any of your thresholds, which is what you want for a staging box or a site you are already working on.

DNS record types

DNS Monitor settings let you choose which record types are watched: A, AAAA, MX, TXT, CNAME, CAA, SOA and DNSSEC. Watching fewer types means fewer routine DNS changes reported, by push and, if you switch on DNS Email Alert, by email.

Offline warning

On by default. It tells you when the device itself has lost its connection, because that is the moment monitoring stops. Leave it on if you want to know your coverage has a gap.

Common questions

The things people ask once the alerts start arriving

Are the email alerts the same as the notifications?

They cover the same events, but they are not the same messages. Email carries more: the failure reason in the subject, the HTTP status and timing, a list of what changed, and a paragraph on what to do. Both show the same Before and Now. So a site going down produces a short banner on your phone and a fuller email to your inbox. The routine background check summary never arrives by email, and DNS record changes are emailed only if you switch on DNS Email Alert.

Why did I get the same alert twice?

The app alerts on transitions and on distinct problems, never on a repeating condition. You get a "site down" and later a "site back online" — that is a pair, not a duplicate. Likewise, an SSL certificate alerts once per threshold band it reaches, so a certificate three months out produces a green notice, an orange one at a month, a red one in the final week, and a green “renewed” notice once the new certificate is in place.

Can I change the number of days before a certificate alert?

Yes. Alert Settings has three thresholds — Green, Orange and Red — and the defaults are 90, 30 and 7 days. You can set each anywhere from 0 to 100 days, as long as Red is less than or equal to Orange and Orange less than or equal to Green, so the warnings always arrive in a sensible order.

How do I turn a notification off?

Two different switches cover two different things. The Alerts toggle on a site card decides whether that site sends alerts at all. Alert Settings decides how alerts behave globally: the notification sound, the certificate thresholds, email recipients per severity level, and the DNS change emails. The background check summary has its own switch there too.

The summary notification is silent. Is that a bug?

No, it is deliberate. The summary reports that routine monitoring happened, usually while you are not looking at the phone, so it uses a quiet channel of its own and never plays a sound. Your notification sound setting stays about the alerts that need you.

Why is the monitoring stalled alert different from the others?

Because it reports on the app rather than on your site. Every other alert needs a check to complete in order to fire, so if checks stop completing, silence would look identical to success. That alert is the only one that reasons about the absence of results, which is why it can arrive while every site is perfectly healthy.

Do I need an email account configured to get notifications?

No. Push notifications are delivered by the operating system, with nothing to configure beyond allowing notifications on your phone. Email is a separate channel you opt into in Email Configuration, and without a mailbox connected nothing is ever emailed. Waiting until you actually want the email copy is a perfectly good choice, because everything described on this page still arrives without it.

Which alerts never arrive by email?

Only the routine background check summary, which stays on the phone. DNS record changes are emailed only once you switch on DNS Email Alert in Alert Settings, which is off by default. Every other alert has an email version, listed in the table above.

What happens when I tap a notification?

Beyond Site opens at its Notifications screen (Toolkit › Notifications), whether the app was open, in the background or closed. Every alert is kept there with its date, its time on a 24-hour clock and its Before and Now. Tap an entry to expand it, or long-press it to copy the details for an email, chat or ticket.

Related

Where these notifications come from, and what the app is checking

User Guide

A walkthrough of the app screen by screen, showing where each result appears and the settings that control it.

Open the guide →

Glossary

Plain-language definitions of the monitoring, SSL, DNS and security terms these alerts use.

Read the glossary →

App Guide

Getting started, the key screens, and the tips that make the most difference.

Open the app guide →