Operations

Health Monitoring

The /healthz endpoint is a health check provided by the healthz.php mu-plugin. In its default mode, it returns a 200 response after verifying database connectivity (SELECT 1). With ?detail it also checks Redis, OPcache, disk space, and cron health. Use this endpoint for uptime monitoring — a 200 response confirms the application and database are both responding.

Uptime Monitoring Setup

Point your monitoring service (Uptime Robot, Uptime Kuma, etc.) at:

https://whallc.com/healthz

The endpoint bypasses both Cloudflare WAF rules and cache rules, so a 200 response means the origin server is actually handling requests — not just Cloudflare serving a cached page.

Do's and Don'ts

Ephemeral Storage

Heroku dynos have an ephemeral filesystem. Any files written to disk during runtime are lost when the dyno restarts, which happens:

• On every deploy
• At least once every 24 hours (Heroku's daily dyno cycling)
• When scaling or restarting manually

What This Means

• Media uploads must go to S3. The yax-offload-media plugin handles this automatically — uploads are written to S3 and URLs are rewritten. Files are not stored on the dyno filesystem.
• Don't rely on local file writes. Anything that writes to /tmp or the filesystem (log files, generated reports, cached files) will disappear on restart.
• WordPress core and plugins are part of the deploy artifact. They're baked into the dist/ build, not installed at runtime. This is why the build step exists — everything the application needs is in the artifact.
• composer install runs on container startup. The entrypoint script ensures dependencies are present, but this is a safety net — the deploy artifact should already be complete.

Common Pitfalls

• Poorly coded plugins — Any plugin that uses the WordPress upload API will work fine — yax-offload-media handles the S3 offloading automatically. Problems only arise with plugins that bypass the upload API and write directly to the filesystem.
• WordPress debug log — wp-content/debug.log is written to the ephemeral filesystem. It's useful for debugging during a session but don't rely on it persisting. Use heroku logs instead.
• Scheduled tasks — WP-Cron runs on page visits. If the site has low traffic, cron jobs may not fire reliably. Heroku Scheduler or an external cron service is more reliable for critical tasks.

Logging

Heroku Logs

Application logs are available via the Heroku CLI:

# Tail all logs
heroku logs --tail --app womens-healthcare-associates

# Filter to web process
heroku logs --tail --app womens-healthcare-associates --ps web

# Recent logs (last 1500 lines)
heroku logs -n 1500 --app womens-healthcare-associates

Local Development

# All container logs
npm run logs

# Specific service
npm run logs:wordpress
npm run logs:nginx
npm run logs:db

# Log viewer UI
# Dozzle at localhost:8888

What Gets Logged

• Nginx — Access logs and error logs. Shows request URLs, response codes, and upstream PHP-FPM errors.
• PHP-FPM — PHP errors, warnings, and notices. Controlled by WORDPRESS_DEBUG and WORDPRESS_DEBUG_LOG env vars.
• WordPress — When WP_DEBUG_LOG is enabled, WordPress writes to wp-content/debug.log (ephemeral on Heroku).
• yax-audit-log — Tracks admin actions (post edits, plugin changes, option updates) in the database, not the filesystem.

Deploys

Pre-Deploy Checklist

1. Theme assets built? Run npm run production in the theme directory if CSS/JS changed. Commit assets/dist/.
2. Tests pass? Run npm test if Playwright tests exist for the feature.
3. Staging verified? Merge to staging first, verify on staging.whallc.com.
4. Database changes? If the deploy requires database changes (new options, updated ACF field groups), plan for those separately — the deploy only ships code.

Post-Deploy Verification

1. Check /healthz returns 200
2. Spot-check key pages (homepage, provider listing, a provider detail page)
3. Check the browser console for JS errors
4. If Cloudflare cache is stale, purge it

Rollback

Heroku keeps previous releases. To roll back:

# See recent releases
heroku releases --app womens-healthcare-associates

# Roll back to previous release
heroku rollback --app womens-healthcare-associates

Scheduled Tasks

WordPress cron (wp-cron.php) is triggered by page visits. On a site with moderate traffic this is usually fine, but be aware:

• Low-traffic periods (nights, weekends) may delay scheduled tasks
• Long-running tasks can time out on Heroku's 30-second request limit
• The wp-crontrol plugin is installed for viewing and managing scheduled events in wp-admin

Database

Backups

Amazon RDS handles database backups. For manual exports:

# Export via WP-CLI (local dev)
npm run wp -- db export backup.sql

# Import
npm run wp -- db import backup.sql

Search and Replace

When migrating data between environments, URLs need to be rewritten. The better-search-replace and search-and-replace plugins handle this in wp-admin. For CLI:

npm run wp -- search-replace 'https://whallc.com' 'https://whallc.joeyyax.dev' --dry-run

Always run with --dry-run first.

Version Control

All code changes go through Git. The branch workflow and what's tracked are documented in Deployment. Key points:

• Never edit files directly on the server — ephemeral storage means changes are lost on the next deploy
• Always commit compiled theme assets (assets/dist/) after running npm run production
• Always commit composer.lock — it pins exact dependency versions

Managed Services

See Contacts for support and escalation information.