What is a render probe and why HTTP monitoring isn't enough
Standard HTTP monitoring checks whether the server responds with a 200 status and whether the expected phrase appears in the page content. That's enough to detect a complete server outage, but it won't tell you that the page layout broke after a CSS update, that an external widget corrupted the design, or that Cloudflare/LiteSpeed is serving a bot wall instead of actual content.
A render probe — also known as visual regression testing — goes a step further. It launches a real browser (Chromium via Puppeteer/Browsershot), renders the page, and captures a CSS snapshot (getComputedStyle) for key elements. Subsequent runs compare the new snapshot against a stored baseline — any deviation signals a potential visual problem.
Cyberapis v0.5.0 introduces this verification layer. The system also gains an external confirmation mechanism — a second, independent vantage point (GitHub Actions) that confirms an outage before an alert is sent. Why? Because a single false alarm at 3 AM can destroy trust in your entire monitoring system.
New Features
Render Probe — Visual Regression Detection
The system launches Chromium via Browsershot, renders the page, and stores a getComputedStyle snapshot for key elements as a baseline. Each subsequent probe compares the result against the baseline — differences exceeding the tolerance threshold trigger an alert. The snapshot includes extended CSS properties: fontSize, lineHeight, marginTop, paddingTop, maxWidth, plus selector fallbacks for common CMS layouts.
External Confirmation via GitHub Actions
A second vantage point that confirms an outage before the system sends a notification. The app dispatches a GitHub Actions workflow to probe the URL from external infrastructure. An email alert is only sent after the external probe confirms the outage. The authorization token flows through GitHub Secrets, not workflow_dispatch inputs.
Alert Debouncing — Protection Against False Alarms
Configurable MONITORING_ALERT_CONSECUTIVE_FAILURES threshold (default 2) — HTTP alerts are only sent after N consecutive failures. Set to 1 for immediate alerting.
Monitoring Pause/Resume
Each monitoring entry can be paused (is_paused) — the scheduler and manual invocations skip it, and alerts are not sent. The Filament panel shows play/pause icons, with a ternary filter to show only active, only paused, or all entries.
HTML Sanity Check
After a successful HTTP check and phrase match, the system scans page HTML for common error-page patterns (MonitoringHtmlSanityChecker). The result is stored in the monitoring_results.sanity_ok column.
Bug Fixes
Render probe cache bypass
Each probe uses a fresh Chromium profile directory, a ?cyberapis_probe= cache buster parameter, Cache-Control: no-cache header, and --disable-http-cache flag. This eliminates the risk of comparing against a cached page version.
Browsershot on production after config:cache
All BROWSERSHOT_* settings moved to config/monitoring.php (browsershot.* key). Code uses config() instead of env(), so the Chrome path is not lost after deployment with config:cache.
Frontend monitoring list — data leak
Logged-in users on the homepage and /monitorings could see all records in the database. They now only see their own monitoring entries (user_id), matching the Filament panel behavior.
User passwords — double hashing
The Filament form used dehydrateStateUsing + Hash::make in the page handler, producing a double hash. Passwords now go to the hashed cast on the User model without additional hashing.
External confirmation — security hardening
The callback token no longer passes through GitHub workflow_dispatch inputs (visible in logs). The workflow reads secrets.MONITORING_EXTERNAL_CONFIRM_CALLBACK_TOKEN — the same value as the app's .env.
Changes & Improvements
Monitoring failure email — more context
Removed the lengthy note equating HTML sanity with CSS/layout scope from the alert template. Added a concise "style templates / render" row showing the latest render probe status (disabled / no data / OK / error + optional mismatch summary).
Cron script with flock
cron-script.sh runs monitor:check-websites under flock -n, preventing overlapping scheduler invocations from stacking up.