How this monitoring stack works in practice
On my server, monitoring is not a separate dashboard project; it is part of the way I run the platform every day. Before and after important changes in WordPress, nginx, or Docker services, I validate health, behavior, and user impact as one connected workflow.
At infrastructure level, Prometheus collects metrics every 15 seconds, Node Exporter gives host visibility, and cAdvisor adds container-level telemetry. For logs, Promtail ships both Docker JSON logs and nginx logs into Loki. Tempo is enabled for OTLP traces when I need deeper request-level visibility. Grafana sits on top of this stack with provisioned data sources, so metrics, logs, and traces stay connected instead of living in separate tools.
Plausible + WordPress: how I configured it
For analytics, I run Plausible Community Edition in Docker with PostgreSQL and ClickHouse. On the WordPress side, I use the Plausible plugin in self-hosted mode for macarare.com, and load the tracker as a first-party script from /js/pa-...js. Events are sent to /p/event, which is proxied by nginx to Plausible ingest. I also keep compatibility paths for Plausible plugin API and tracker resources behind nginx, so WordPress integration remains stable after cache or plugin changes.
In practice, this data helps me in three ways. For monitoring, I can quickly spot real traffic anomalies after a deployment, not just infrastructure-level issues. For debugging, I can correlate drops, 404 spikes, search/form behavior, and endpoint activity with logs and service metrics to isolate root cause faster. For analysis, I use Plausible to validate if navigation, content structure, or SEO changes actually improve user flow instead of guessing from intuition.
How I use this in operations
When something looks wrong, I start from external symptoms (uptime and traffic), then move into metrics/logs, and finally confirm recovery by watching events and pageviews normalize. This loop makes the stack easier to maintain and reduces blind troubleshooting.
External Monitoring
Having a great dashboard is very useful, but it becomes pointless if the server loses connection. To ensure proper monitoring and receive alerts when my website or services go down, I configured a free Better Stack account to regularly check each service with periodic pings. If any service stops responding, Better Stack sends an alert email to the mail server hosted on my home server.
Main System Dashboard
This is my base system dashboard, where I monitor core host readouts such as CPU, memory, disk, network, and temperature.
Docker Groups Dashboard
To monitor containers, I keep two complementary dashboards with different detail levels.
In this grouped view, containers are organized by service (WordPress, Nextcloud, Plausible, etc.) and averaged per group, which helps me identify service-level anomalies quickly.
In this capture, Plausible shows higher network traffic and WordPress shows a small increase in disk writes, which matches the edits and media uploads for this post.
Per-Container Dashboard
When I detect unusual behavior in the grouped view, I switch to the per-container dashboard to isolate the exact container behind the incident.
Skills Developed
Telemetry
Engineering
Designed and operated Prometheus, Node Exporter, and cAdvisor collection pipelines for host and container visibility.
Product
Analytics Ops
Implemented self-hosted Plausible + WordPress first-party tracking and stable event proxying for reliable analytics.
Tracing &
Observability
Configured Tempo and connected metrics, logs, and traces in Grafana to speed up root-cause analysis.
Incident
Debugging
Correlated analytics anomalies with nginx logs and infrastructure telemetry to isolate incidents faster.
Release Impact
Validation
Validated post-release behavior by comparing user analytics and system telemetry instead of relying on assumptions.
Related Services
NAS (NextCloud)
Monitoring
WordPress
NGINX
