MonSpark Monitoring

MonSpark Monitoring

Use MonSpark when the project already has a paid uptime/cron-monitoring tool and you want one monitoring home for server checks, Laravel scheduler heartbeats, app uptime, SSL/DNS checks, alert channels, escalation, and status pages.

This guide is the MonSpark-specific companion to the Admin-Server alerting setup and Phase 7 monitoring choices. It does not replace the local Admin-Server scripts; it gives those scripts an external heartbeat and alerting destination.

flowchart TD
  A["Admin-Server scripts"] --> B["HEARTBEAT_* URLs in server.env"]
  B --> C["MonSpark Cron Job monitors"]
  D["Laravel scheduler"] --> E["MONSPARK_CRON_URL"]
  E --> C
  C --> F["Alert channels and escalation"]
  G["Uptime / SSL / DNS checks"] --> F
  F --> H["Operator response"]

When To Use It

Use MonSpark if the operator already pays for it, has AppSumo/lifetime access, or wants one tool for uptime and heartbeat checks. The same heartbeat slot can also be provided by Healthchecks.io, Better Stack, Cronitor, or UptimeRobot heartbeats; do not create a second paid monitoring account just because a guide example names one provider.

Secrets stay out of docs and git

MonSpark API keys and heartbeat URLs are credentials. Store them in the shared infrastructure vault recorded in Zaj-PROJECT.md (default example: General-Dev) and copy only runtime values into gitignored .env or ~/Admin-Server/config/server.env. Never paste live URLs into README files, commits, screenshots, or chat.

Setup Flow

1. Confirm account and workspace

Log in to MonSpark, confirm the workspace/billing state, and record the non-secret account label in Zaj-PROJECT.md.

When an agent helps in the MonSpark console, follow the vendor console automation guide: the operator supplies the logged-in browser, the agent drives the non-secret monitor fields, and heartbeat URLs move through the clipboard bridge without appearing in chat or command output.

Monitoring provider: MonSpark
Monitoring workspace: <workspace-name>
Shared infra vault: <actual-vault-name>
Credential pointers:
- MonSpark API key: op://<vault>/MonSpark/API_KEY
- MonSpark heartbeat URLs: op://<vault>/MonSpark/Admin-Server Heartbeats

2. Create external monitors

Create the monitors that match the project risk:

Monitor	Purpose	Minimum signal
Uptime	App responds over HTTPS	200 or expected redirect
SSL	Cert expiry and TLS health	Valid cert, expiry alert
DNS	Wrong-origin or stale-DNS drift	A/AAAA/CNAME matches expected provider
Domain	Domain expiry	Renewal warning
Cron Job	Heartbeat for scheduled scripts	Expected ping interval plus grace
Status Page	Public/internal incident surface	Linked to uptime monitors

3. Wire Admin-Server heartbeats

Create one MonSpark Cron Job monitor per Admin-Server script and copy the heartbeat URLs into ~/Admin-Server/config/server.env.

Console path: Cron Job → Create Monitor → name/interval/grace → Copy heartbeat URL. Use the copied URL for the matching HEARTBEAT_* slot.

Admin-Server script	server.env slot	MonSpark monitor name
Snapshot	HEARTBEAT_SNAPSHOT	<project> <env> Admin Snapshot
Integrity	HEARTBEAT_INTEGRITY	<project> <env> Admin Integrity
Resource	HEARTBEAT_RESOURCE	<project> <env> Admin Resource
Error log	HEARTBEAT_ERRORLOG	<project> <env> Admin Error Log
Inventory	HEARTBEAT_INVENTORY	<project> <env> Admin Inventory

Use the same provider pattern for every environment. The server label in the alert payload distinguishes staging from production; the secret storage and slot names stay consistent.

4. Wire Laravel scheduler heartbeat

If the app has Laravel scheduler jobs, create a separate MonSpark Cron Job monitor and store it as MONSPARK_CRON_URL in the app vault/env.

use Illuminate\Support\Facades\Schedule;

Schedule::command('queue:work --stop-when-empty')
    ->everyMinute()
    ->pingOnSuccess(env('MONSPARK_CRON_URL'));

If the vendor still uses app/Console/Kernel.php, place the ping there. If the app uses Laravel 11 style scheduling, place it in routes/console.php or the project’s scheduler bootstrap, matching the existing codebase.

5. Wire alert channels and escalation

Map the channels before creating monitors:

Alert route	Common channel	Use
Ops	#server-alerts	Admin-Server failures, stale cron, disk, SSL, DNS
Deploys	#deployments	Deployer notifications
App alerts	#app-alerts	Laravel errors, Sentry, synthetic app checks
Backups	ops or backup channel	Backup failure/age alerts

Add escalation contacts only after the base channel test works. Do not mark alerting ready until a synthetic alert reaches the expected channel.

6. Verify end to end

Run the Admin-Server test from the server after server.env is wired:

cd ~/Admin-Server
bash scripts/alert-helper.sh INFO "MonSpark/Admin-Server alerting smoke test for $(hostname)" ops

# Expected:
# - command exits 0
# - the configured ops channel receives the message
# - the relevant MonSpark heartbeat monitor shows a recent ping after the next scheduled script run

If the message does not arrive, treat alerting as inactive even if status.sh is green. status.sh proves the local scripts are alive; it does not prove external destinations are wired.

Checklist

• MonSpark account/workspace recorded in Zaj-PROJECT.md.
• API key and heartbeat URLs stored in the shared infrastructure vault, not in git.
• Admin-Server HEARTBEAT_* slots populated or explicitly waived.
• Laravel MONSPARK_CRON_URL added only when scheduler heartbeat monitoring is adopted.
• Alert channel mapping documented.
• Synthetic Admin-Server alert reached the expected channel.
• Status page and escalation settings reviewed.

Related Pages

• Setup shared hosting
• Monitoring & observability
• Stage schedule and schema checks