A Ghost publication is more than its homepage. Publishing can fail while cached posts remain readable; member sign-in can break while public content works; and a webhook failure can leave a headless frontend stale. Ghost uptime monitoring should cover the reader, editor, member, and integration paths separately.
Check each Ghost surface
| Surface | Example check | Failure caught |
|---|---|---|
| Publication | Homepage plus current post, stable text required | Theme, routing, database, CDN |
| Site metadata | GET /ghost/api/admin/site/ |
Ghost API reachability and configured URL |
| Content API | Read a known post or settings resource | Headless content delivery |
| Ghost Admin | Admin login shell, no credentials in URL | Editor access and asset loading |
| Members | Sign-in or signup page; periodic synthetic account flow | Portal, email, and session regressions |
| Webhooks | End-to-end publish canary in staging or a heartbeat receiver | Stale integrations or headless rebuilds |
| Newsletter | Provider metrics and a controlled seed inbox | Sending or delivery failures |
Ghost documents the unauthenticated, read-only Site endpoint and the read-only Content API. Validate expected JSON fields rather than accepting any 200.
Hosted, self-hosted, and headless caveats
- Ghost(Pro): Ghost manages the platform, but you still own custom DNS, theme behavior, integrations, member journeys, and content correctness.
- Self-hosted Ghost: add process restart count, Node.js memory, MySQL availability, reverse-proxy health, disk, image storage, SMTP, and backup freshness.
- Headless Ghost: monitor Ghost's Content API and the frontend deployment separately. A cached frontend can look healthy after content delivery or rebuild webhooks have stopped.
- Multiple newsletters or domains: give each sender/domain and publication hostname its own delivery and TLS checks.
Ghost webhooks send POST requests for events such as site.changed and post.published. Record receipt, processing outcome, and age of the last successful event. A successful delivery to your endpoint does not prove the downstream build or cache purge completed.
Test publishing without production noise
Use a staging publication or a private canary post. Exercise draft-to-published state, verify it appears through the Content API and frontend, then remove or unpublish it. Do not publish synthetic posts to a live RSS feed or send test newsletters to real members.
For live monitoring, check public read paths frequently and use lower-frequency controlled tests for member email, newsletter delivery, and publish webhooks.
Ghost monitoring checklist
- Homepage and current post validated
- Site or Content API response validated
- Admin login assets checked
- Member flow tested with a dedicated account
- Publish webhook receipt and downstream completion tracked
- Newsletter canary and provider failures monitored
- Custom-domain DNS and TLS checked
- Self-hosted process, database, storage, and mail signals covered
Use content-change monitoring for stale or unexpected pages, webhook monitoring for integrations, and email monitoring for newsletter infrastructure.
Start monitoring your Ghost publication with external page, API, content, response-time, and TLS checks.