Etter Digital Status Monitor

03 / Screenshots

Public Status Dashboard

Overview

Etter Digital Status Monitor is a distributed monitoring system built to track the availability of services running across the Etter Digital environment.

The system separates monitoring from presentation. A Python monitoring agent running on a Raspberry Pi performs HTTP and HTTPS checks against configured services. Results are submitted to a Cloudflare Worker, which provides the API layer and stores monitoring data in Cloudflare D1.

The public status interface at status.etterdigital.dev uses this data to report the current state of monitored services.

The source code is available in the Etter Digital Status Monitor GitHub repository.

Objective

The goal was to build a real monitoring system rather than a static status page that manually reports whether services are online.

The system needed to:

• Perform actual availability checks against deployed services
• Run independently of the services being monitored
• Store monitoring results outside the Raspberry Pi
• Provide a public API for current service status
• Protect the monitoring ingestion endpoint from unauthorized submissions
• Continue operating without exposing the Raspberry Pi directly to the internet
• Support additional services as the Etter Digital environment grows

This also created a way to publicly demonstrate the operational side of projects hosted under etterdigital.dev.

Requirements

The monitoring platform was designed around several practical requirements:

• HTTP and HTTPS endpoint monitoring
• Automated checks from an always-on Raspberry Pi
• Authenticated submission of monitoring results
• Persistent storage for service and check data
• Public access to service status
• Separation between public status information and protected ingestion
• Support for multiple services
• Lightweight resource usage on the Raspberry Pi
• No requirement to expose inbound ports on the home network

Architecture

The monitoring system is split between local infrastructure and Cloudflare-hosted services.

The Raspberry Pi acts as the monitoring node. A Python agent performs checks against configured public endpoints and determines whether those services respond successfully.

Monitoring results are sent over HTTPS to a Cloudflare Worker.

The Worker acts as the boundary between the monitoring agent and the stored status data. It exposes separate endpoints for submitting monitoring results and retrieving public service status.

Cloudflare D1 provides persistent storage for service configuration and monitoring data.

This architecture keeps the monitoring workload lightweight on the Raspberry Pi while moving the public API and persistent monitoring data to Cloudflare infrastructure.

It also prevents the public status page from depending directly on connectivity to the Raspberry Pi.

Implementation

Monitoring Agent

The monitoring agent runs on the Raspberry Pi using Python.

The project is installed under:

~/etterdigital-status/monitor

A Python virtual environment isolates the monitoring application’s dependencies:

.venv

The monitor can be executed using:

python -m status_monitor.main

During a monitoring cycle, the agent checks each configured service and records information such as whether the request succeeded, the HTTP response status, and request timing.

The results are then submitted to the remote ingestion API.

Cloudflare Worker

A Cloudflare Worker provides the API layer for the monitoring platform.

The Worker handles both public status retrieval and protected monitoring ingestion.

The public status endpoint is:

GET /api/status

It returns the current monitoring state and service information.

Monitoring results are submitted through:

POST /api/checks

The ingestion endpoint requires authentication and is not intended for public submissions.

Ingestion Authentication

The monitoring agent authenticates with the Worker using a bearer token.

Requests to the ingestion endpoint include:

Authorization: Bearer <INGEST_TOKEN>

The token is stored as a secret rather than being hardcoded into the repository.

On the Worker side, the secret is managed through the Cloudflare Workers secret system.

This prevents the ingestion credential from being exposed in source code while still allowing the Raspberry Pi monitor to authenticate when submitting results.

Cloudflare D1

Cloudflare D1 is used as the persistent data layer for the platform.

The database maintains information about monitored services and allows the Worker to determine which services should be included in public status responses.

Service records include information such as:

• Internal identifier
• Service slug
• Display name
• Public URL
• Enabled state
• Public visibility
• Lifecycle state

This provides a structured way to add or disable monitored services without redesigning the API.

Linux Service Management

The Raspberry Pi monitoring agent is managed through systemd.

The service is named:

etterdigital-status-monitor.service

Using systemd provides a Linux-native way to execute and manage the monitoring process without requiring an interactive terminal session.

It also makes the monitoring agent part of the host’s normal service-management workflow.

Monitoring Flow

A typical monitoring cycle follows this path:

1. The Raspberry Pi monitoring agent loads the configured services.
2. The agent performs HTTP or HTTPS checks against those services.
3. Results are collected by the Python monitoring process.
4. The agent sends the results to the Cloudflare Worker over HTTPS.
5. The Worker authenticates the request using the ingestion token.
6. Valid results are written to Cloudflare D1.
7. Public clients retrieve current service health through /api/status.
8. The public status interface presents the resulting service state.

This separates active monitoring, ingestion, storage, and public presentation into distinct responsibilities.

Challenges

Authenticated Ingestion

During initial deployment, monitoring submissions returned HTTP 401 responses.

The monitoring process itself was functioning, but the Worker rejected submitted results because the authentication configuration between the Raspberry Pi agent and the Worker did not match correctly.

This was important to troubleshoot because allowing unauthenticated ingestion would have made it possible for arbitrary clients to submit false monitoring results.

Local and Remote D1 Environments

Development involved both local and remote D1 environments.

The local database was useful for Worker development and testing, while the deployed Worker required the remote D1 database and binding to be configured correctly.

Keeping these environments distinct was necessary to avoid assuming that locally created data automatically existed in the deployed database.

Monitoring a Growing Environment

The platform was initially configured around a small number of Etter Digital services, including:

• etterdigital.dev
• projects.etterdigital.dev
• dashboard.etterdigital.dev

The architecture needed to support adding additional services without creating a new monitoring implementation for each one.

Distinguishing Monitoring From Service State

A status system needs to distinguish between the state of a monitored service and the state of the monitoring system itself.

A service may have no recent monitoring information because monitoring has not yet produced a valid result. That is different from confirming that the service is offline.

The API therefore needs to represent unknown or inactive monitoring conditions without presenting them as confirmed outages.

Solutions

Protected Ingestion Endpoint

The monitoring submission endpoint was protected with bearer-token authentication.

The Raspberry Pi monitor sends the ingestion credential with each submission, while the Worker validates it before accepting monitoring results.

After correcting the authentication configuration, the monitoring agent successfully submitted results to the deployed Worker.

Separate Local and Remote Databases

Local D1 development and the deployed D1 environment were treated as separate data stores.

Database operations intended for production were explicitly executed against the remote database rather than relying on local development state.

This made the deployment process more predictable and reduced confusion between development data and live monitoring data.

Service-Based Configuration

Monitored endpoints are represented as service records rather than being embedded directly into the public interface.

This allows services to be enabled, disabled, or assigned visibility independently of the frontend.

The approach also provides a foundation for adding more Etter Digital services as the environment expands.

Distributed Responsibilities

The system deliberately avoids placing every responsibility on the Raspberry Pi.

The Pi performs the actual health checks, while Cloudflare handles the public API and remote data storage.

This keeps the local monitoring agent relatively lightweight and avoids requiring public clients to connect directly to infrastructure on the home network.

Security Considerations

The monitoring architecture separates public and protected functionality.

Public clients can retrieve service status, but monitoring submissions require authentication.

The ingestion credential is stored as a secret and is not committed to the Git repository.

The Raspberry Pi initiates outbound HTTPS requests to Cloudflare rather than accepting public inbound connections for monitoring ingestion.

This reduces the amount of local infrastructure directly exposed to the internet.

The public status API intentionally exposes service-health information, so service metadata should be reviewed before being marked public.

Current Limitations

The monitoring platform is still being expanded.

Current areas for improvement include:

• Longer-term uptime history
• More detailed incident management
• SSL certificate expiration monitoring
• Additional monitoring types beyond basic HTTP and HTTPS availability
• Better visualization of historical response data
• More complete monitoring-agent failure detection
• Backup and recovery procedures for supporting infrastructure

These are planned improvements rather than functionality represented as already complete.

Results

The project currently provides a working monitoring path from the Raspberry Pi to Cloudflare.

The monitoring agent can perform real service checks and submit the resulting state to the authenticated Worker endpoint.

The Worker provides a public status API backed by D1, allowing status.etterdigital.dev to report information based on actual monitoring results rather than manually entered service states.

The project also establishes a reusable monitoring architecture that can be extended as additional Etter Digital services are deployed.

Lessons Learned

This project provided practical experience connecting local infrastructure with cloud-hosted services.

Important areas included:

• Python service development
• Linux service management with systemd
• HTTP health checking
• REST-style API design
• Bearer-token authentication
• Secret management
• Cloudflare Workers
• Cloudflare D1
• Local versus remote deployment environments
• Troubleshooting HTTP authentication failures
• Designing monitoring systems around failure states

One of the most important architectural lessons was that monitoring should not depend entirely on the infrastructure being monitored.

Separating the Raspberry Pi monitoring agent from the public API and data layer creates clearer system boundaries and makes individual components easier to troubleshoot.

Future Improvements

Planned improvements include expanding the platform beyond current-state HTTP monitoring.

Potential additions include:

• Historical uptime calculations
• Response-time history
• Incident creation and resolution tracking
• SSL certificate expiration checks
• Additional service types
• Monitoring-agent heartbeat detection
• Improved status-history visualization
• Automated maintenance-state handling
• Additional operational documentation

Future functionality will be documented as it is implemented rather than represented as part of the current system.