--- layout: default title: "TSAP Status Monitoring System (Documentation)" description: "Documentation for the TSAP Status Monitoring System, including its architecture, monitoring workflow, public status dashboard, and development history." categories: [TSAP Documentation, TSAP Tools] permalink: /tsap/status-monitoring-system/ created: 2026-07-12 --- {% include documentation-notice.html %} The **TSAP Status Monitoring System** provides independent monitoring for services associated with The Sunil Abraham Project (TSAP). It continuously checks the availability and responsiveness of selected public services, stores the results in a private monitoring database, and publishes a publicly accessible status dashboard. This architecture allows the project to retain full control over monitoring behaviour, presentation, and future development while remaining inexpensive and easy to maintain. ## Background As TSAP continued to expand, it became increasingly desirable to monitor the availability of important public services automatically. The initial requirement was intentionally modest. Rather than monitoring dozens of services, the first version focused on confirming that the main website and sitemap remained publicly accessible. Several monitoring approaches were considered, including commercial uptime monitoring services and self-hosted monitoring software. Although these solutions offered many features, they also introduced unnecessary complexity or recurring costs. TSAP generally favours lightweight, transparent, and maintainable solutions that remain compatible with static-site architecture. The final design therefore adopted a small collection of existing cloud services that work together while remaining loosely coupled. ## Objectives The monitoring system was designed to: - Verify that selected TSAP services remain publicly accessible. - Detect outages and unexpected responses. - Record monitoring history. - Measure response times. - Publish a public status dashboard. - Keep monitoring independent from the main website wherever practical. - Remain simple enough to maintain over long periods. ## Architecture The monitoring system consists of several independent components. ```text Visitors │ ▼ status.sunilabraham.in │ ▼ Cloudflare Worker │ ▼ Google Apps Script API ▲ │ Google Apps Script ▲ │ │ ▼ Google Sheets sunilabraham.in ``` Each component performs a single responsibility. Google Apps Script carries out the monitoring, Google Sheets stores the collected data, the Apps Script exposes that information through a JSON API, and a Cloudflare Worker generates the public status dashboard. Separating these responsibilities keeps monitoring, storage, data exchange, and presentation independent of one another, making the system easier to maintain and extend. ## Components ### Google Apps Script Google Apps Script serves as the monitoring engine. A time-driven trigger executes the monitoring script once every hour. During each run, the script checks every enabled service listed in the configuration sheet. For each service it records: - Timestamp - Service name - URL - Status - HTTP response code - Response time - Content verification result - Error message (if applicable) - Notes The monitoring script intentionally performs only data collection. It contains no presentation logic. ### Google Sheets Monitoring results are stored in a private Google Spreadsheet. The spreadsheet currently contains four worksheets. - **Configuration**: Defines the services to monitor together with their expected HTTP response codes and optional content verification strings. - **Checks**: Stores every monitoring result as a permanent historical record. Each monitoring run appends new rows rather than replacing previous results. - **Incidents**: Reserved for future incident tracking. - **Summary**: Reserved for future reporting and statistical summaries. The spreadsheet functions as the project's monitoring database while remaining transparent and easy to inspect manually. ### JSON API Rather than generating HTML directly, the Apps Script exposes monitoring data through a lightweight JSON endpoint. The public endpoint returns the latest monitoring information together with additional metadata required by the status dashboard. This separation allows the presentation layer to evolve independently from the monitoring engine and avoids coupling the user interface to Google Apps Script. ### Cloudflare Worker The public status dashboard is generated by a Cloudflare Worker rather than Google Apps Script. The Worker retrieves monitoring data from the Apps Script JSON endpoint and renders a lightweight HTML page for visitors. Separating the presentation layer from the monitoring engine provides several advantages. The HTML, styling, and layout can evolve independently without affecting the monitoring logic. It also avoids exposing Google Apps Script pages directly to visitors while allowing the dashboard to be served through the project's own status domain. The Worker currently serves the dashboard at: ```text https://status.sunilabraham.in/ ``` A fallback Cloudflare Workers URL is also available: ```text https://status.sunilabrahamindia.workers.dev/ ``` The fallback address remains useful if the custom domain experiences DNS-related problems. Because the Worker consumes a JSON API rather than directly accessing the spreadsheet, the monitoring backend and the presentation layer remain loosely coupled. ## Monitoring Workflow Each monitoring cycle follows a simple sequence. 1. Google Apps Script reads the list of enabled services from the Configuration worksheet. 2. Each service is requested using an HTTP fetch. 3. The returned HTTP status code is compared with the expected value. 4. Where configured, the returned page content is checked for expected text. 5. Response time is measured. 6. The result is written to the Checks worksheet. 7. The Apps Script JSON API exposes the latest monitoring data. 8. Cloudflare Workers retrieve the JSON and generate the public dashboard. Each monitoring run appends new records instead of replacing previous ones. This creates a permanent monitoring history that can later be used for trend analysis, uptime statistics, and incident investigation. ## Public Status Dashboard The public dashboard presents the most recent monitoring information in a human-readable format. The dashboard includes: - Overall operational status. - Individual service status. - HTTP response times. - Last successful check. - Recent monitoring history. - Information explaining the monitoring architecture. - Primary and fallback dashboard URLs. The dashboard automatically adapts to both light and dark mode and is designed to remain usable on desktop and mobile devices. Unlike the monitoring engine itself, the dashboard contains no monitoring logic. It simply presents information already collected and exposed through the JSON API. ## Independent Monitoring One of the project's primary design goals was to ensure that monitoring remains as independent as reasonably possible from the main website. The TSAP website itself is published using GitHub Pages. If the public status page were also hosted on GitHub Pages, an outage affecting GitHub infrastructure could make both the website and its status page unavailable simultaneously. To reduce this dependency, the dashboard is served separately through Cloudflare Workers while monitoring is performed by Google Apps Script. Although the monitoring system still relies on third-party cloud services, separating these responsibilities makes it less likely that a single infrastructure problem will affect every component simultaneously. This approach provides visitors with a more reliable indication of the website's operational status during outages. ## External Links - [Status Dashboard](https://status.sunilabraham.in/) - [Fallback Status Dashboard](https://status.sunilabrahamindia.workers.dev/)