TSAP Status Monitoring System (Documentation)

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.

                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:

https://status.sunilabraham.in/

A fallback Cloudflare Workers URL is also available:

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. The Cloudflare Worker retrieves 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.

Interpreting Response Times

The monitoring system records the total time taken by Google Apps Script to complete each HTTP request. These measurements are useful for identifying unusual delays and longer-term performance patterns, but they should not be interpreted as direct measurements of website rendering speed.

A recorded response time can be affected by several parts of the request path, including:

• The Google Apps Script execution environment.
• Network routing between the monitoring system and the destination.
• DNS and connection establishment.
• TLS negotiation.
• Content delivery networks and caching layers.
• Temporary latency at the hosting provider or other intermediate infrastructure.

The TSAP website is served through Cloudflare with GitHub Pages as its hosting origin. An isolated slow response may therefore occur even when the website remains fully operational.

During testing in July 2026, occasional multi-second response times were observed while the affected requests continued to return HTTP 200 responses and passed content verification. Subsequent requests generally returned to normal response times. These events are therefore recorded as performance observations rather than automatically being classified as outages.

Response-time trends should be evaluated across multiple checks. Sustained elevated response times or repeated failures are more significant than an isolated latency spike.

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
• Fallback Status Dashboard

📄 This page was created on 12 July 2026. You can view its history on GitHub, preview the fileTip: Press Alt+Shift+G, or inspect the underlying source. Last updated on 19 July 2026.