Uptime, SSL and the public status page

Exception tracking tells you the app is failing; uptime monitoring tells you it isn't answering at all. Quiet Guard probes a URL you choose, alerts on the transition, keeps a latency history, watches the TLS certificate, and can share it all on a public status page.

The active probe

Set a check URL in the project's Settings (Uptime monitoring section). Every five minutes, Quiet Guard sends a GET request:

• Any status below 400 counts as up (redirects included), with the response time recorded as latency.
• A 4xx/5xx, a timeout (10 s) or a connection error counts as down.
• The URL must be public: private and internal addresses are rejected by the same anti-SSRF guard that protects webhooks.

Prefer a lightweight endpoint like Laravel's /up health route over a heavy homepage: you are measuring availability, not rendering time.

Down / recovered alerts

Alerts fire on transitions, not on every failing check: one alert when the site goes down, one when it comes back. Subscribe channels to the uptime.down and uptime.recovered events on the project's Alerts tab (see Alerting). Alert-storm protection applies.

Because probes run every five minutes, an outage shorter than the gap between two checks can go unnoticed, the probe is a smoke detector, not a packet analyzer.

Latency history

Every probe stores a sample. The project overview renders a 24-hour response-time chart (30-minute buckets, averages of successful checks; outage windows appear as gaps, never as fake zeros). Samples are kept seven days, independently of your plan's event retention.

TLS certificate expiry

For https check URLs, a daily job reads the certificate directly off the socket, it works even when the chain is broken, and stores the expiry date, shown on the project overview.

You are warned twice per certificate: once when it crosses 14 days to expiry, once more at 3 days (ssl.expiring event, same channels). A renewed certificate resets the cycle. An already expired certificate needs no special alert: the five-minute probe verifies peers, so the site simply goes down and alerts through that path.

Domain registration expiry

A certificate can renew itself; a domain cannot. A daily job asks the domain's registry, over RDAP, when its registration expires, and shows the date on the project overview.

You are warned twice per domain: once when it crosses 30 days to expiry, once more at 7 days (domain.expiring event, same channels), wider thresholds than the certificate's on purpose, since a domain renewal is a payment rather than an automated rotation. A renewal resets the cycle. Past the expiry date the registration is genuinely lapsed, which the project's Incidents tab records: a lapsed domain enters a redemption period that costs a fee to reverse at the registrar.

DNS zone changes

A second daily job compares the zone, A, AAAA, MX, NS and TXT records, for the check URL's host against what was last observed. The first observation is a baseline, never an alert; every change after it fires dns.changed (same channels), naming exactly which record types moved and their values before and after. Time-to-live values are ignored on purpose: they count down between two lookups of an unchanged zone and would alert on every sweep. This catches a hijacked domain, a broken mail setup or an accidental edit before a customer notices.

Exposed files

Once switched on from a project's Vulnerabilities tab, Quiet Guard asks the monitored site every morning for a closed list of paths that should never answer publicly. The base is the origin of the monitored URL (scheme, host, port), never its path.

A path is reported exposed only when it answers 200 (or 206) and its first bytes look like what we are looking for: a single-page application that serves its home page for every unknown address is not reported. A redirect, a 401, a 403, a 404 or a 410 count as protected; any other answer (a 429 rate limit, a 408, a 5xx) or a network error concludes nothing, and the known state is kept.

Nothing the site answers is kept. Quiet Guard reads at most 8 KiB, decides in memory, and keeps only the path, the HTTP status and the severity. Requests carry the user agent Quiet Guard-Exposure/1.0, so you can recognise them in your logs or allow them in your web application firewall.

A new exposure raises the exposure.detected event (see Alerting). An exposure that stops answering turns "Fixed" without an alert, and alerts again if it comes back. "Ignore" silences a deliberate finding while it answers.

To fix it: point the web server root at the application's public/ directory, block the remaining paths, switch Ignition, Debugbar and Telescope off in production, then rotate every secret that may have been read. Closing the door does not make secret what was already read.

Only switch this check on for a site your team operates.

Incidents

The uptime probe and the domain watch both write to a shared Incidents tab on the project: the source, when it started, how long it lasted or has lasted so far, and a note your team can leave or edit at any time, resolved or still open. For an uptime incident, that note is the one thing from this tab that reaches the public status page below, next to the matching outage window, for a reader who was never given panel access. A domain incident's note stays internal: a lapsed registration is not a failure of the service the status page reports.

The public status page

Flip Public status page in the project's Settings and share the generated link, an unguessable token is the whole URL. The page shows:

• the current state and, when down, since when;
• 7-day availability: overall and as one bar per day;
• current and 24-hour average latency;
• the TLS certificate's validity date;
• the last five outage windows, each with the note left on its incident, when there is one.

Nothing sensitive is exposed: visitors see the project's display name and probe results, never the probed URL, tokens or any application data. Disabling the page keeps the token, so re-enabling restores the same address, links you shared stay valid.

Embeddable badge

The same token also serves a flat SVG badge at /status/{token}/badge.svg: green with the 7-day availability when the site is up, red "down" during an outage, gray "n/a" before the first check. Drop it in a README:

![uptime](https://your-monitor.example/status/{token}/badge.svg)

The exact snippet, with your real token, is shown under the status-page toggle in the project's Settings. The badge refreshes with the same one-minute cache as the page.