Source identity
| Field | Recorded value |
|---|---|
| Source type | GitHub source |
| Original record | Janady13/missionmatch / docs/EXTERNAL_MONITOR_TODO.md |
| Date | Not specified in source |
| Repository | Janady13/missionmatch |
| Revision | 720d47fae476b0d38477ae4401697d372b1ea2bc |
| Branch | feature/opportunity-to-outcome |
| Path or archive member | docs/EXTERNAL_MONITOR_TODO.md |
| Original SHA-256 | afd09f0557e394560330798cc268761d3e1c51c2adf9c78c0e06b9a69f1c8f9c |
| Git blob SHA | 21389d06e460b64508814327f41047f1c609129f |
| Reading-copy SHA-256 | afd09f0557e394560330798cc268761d3e1c51c2adf9c78c0e06b9a69f1c8f9c |
Recovered source transcript
Download complete source text ↓89 lines · 3.9 KB
# EXTERNAL UPTIME MONITOR: STEPS FOR JOSEPH
Written 28 July 2026. This is the one monitoring gap that cannot be closed from
this machine, and the reason is arithmetic rather than effort.
## Why the existing probes do not count
mm-watch.sh runs ON Bubbles, probes 127.0.0.1 and the peer node
mm-offsite-watch.sh runs on megamind-agi, probes the PUBLIC url
The second was added today and it is a real improvement: Bubbles cannot report
its own death, so a probe on another machine catches host failure, nginx failure,
and certificate expiry. It stays.
It is **not external**. megamind-agi is 192.168.1.190 and Bubbles is
192.168.1.132, behind one router and one uplink. Both probes share the ISP, the
WAN address, and the DNS path with the thing they watch, so none of them can see
an ISP outage, a WAN routing failure, or a DNS failure as the internet sees it.
Every machine I can reach is on that LAN, so I cannot fix this by writing code.
## What to add
A third party monitor, free tier, checking three URLs from outside your network.
1 https://missionmatch.thatwebhostingguy.com/ expect 200
2 https://missionmatch.thatwebhostingguy.com/healthz expect 200
3 https://fg-talent.com/ expect 200
Two of those are health endpoints and one is the public site, so a failure tells
you whether the application died or the whole host did.
## UptimeRobot, the shortest path
1. Go to **https://uptimerobot.com** and create a free account. The free tier
allows 50 monitors at 5 minute intervals, which is more than enough.
2. Verify the email address, then **Dashboard, + New monitor**.
3. For each of the three URLs:
- Monitor type: **HTTPS**
- Friendly name: `missionMATCH public`, `missionMATCH health`, `fg-talent`
- URL: one of the three above
- Monitoring interval: **5 minutes**
- Under **Advanced**, set Expected status codes to `200` only. The default
accepts any 2xx or 3xx, which would treat a redirect to an error page as
healthy.
4. **Alert contacts**: add your email. Add SMS or the mobile app if you want to
be woken; the whole point is a channel that is not this network.
5. Set **Alert when down for**: 2 consecutive checks. One failed check is
usually a blip and paging on it trains you to ignore the pager.
## The certificate check, which is the one people forget
In the same tool, add a fourth monitor of type **SSL certificate** (or enable
"Monitor SSL errors" on monitor 1) for
`missionmatch.thatwebhostingguy.com`, alerting **21 days** before expiry.
The cross node probe already watches certificate expiry and reported 66 days
remaining today, so this is redundancy rather than a gap. Redundancy is
appropriate here: a certificate expiring is the failure most likely to happen
while nobody is looking.
## Prove it before you trust it
**Do not skip this.** A monitor that has never fired is indistinguishable from
one that is misconfigured, which is the lesson this build has relearned about
eight times.
1. On Bubbles: `sudo systemctl stop nginx`
2. Wait for two check intervals, about 10 minutes.
3. Confirm you received the alert on the channel you configured.
4. `sudo systemctl start nginx` and confirm the recovery alert arrives.
If no alert arrives, the monitor is decorative and needs fixing before it counts
for anything.
## Alternatives, if you prefer not to use UptimeRobot
Better Stack free tier, 10 monitors, 3 minute checks, nicer alerting
Healthchecks.io better for cron style dead man switches than HTTP uptime
Pingdom paid, more than this needs
Any of them satisfies the requirement. The requirement is only that the prober
sits outside this building's network.
## When it is live
Tell me and I will record it in BUILD_STATE and in ARCHITECTURE section 15, and
mark the cross node probe as what it is: a useful second opinion that is not an
external vantage.