Automated

Web

Monitoring

Build 02

©2026 Nikhil Khedlekar. All rights reserved.

Core Expertise

Generative AI Workflows • Prompt Engineering • Content Automation • Content Strategy • Programmatic SEO • CMS Architecture • Search Intent Strategy • WordPress • Figma • Canva • Analytics

Back to Tools
Build 02

Watchtower Web Monitoring System

A self-healing monitor that watches a login-protected web portal around the clock and emails me the moment something new appears, so nobody has to sit refreshing a page all day.

Self-initiated build · Python on Oracle Cloud · Aug 2026
Self-Healing Sessions
Duplicate Detection
Instant Email Alerts
Always-On on Linux
Stack
Python · Playwright · OCI Linux
Role
Designed, built and deployed (AI-assisted)
Status
Deployed, running as a service
Timeline
Aug 2026
In short

Watchtower is a self-healing web monitor built with Python and Playwright and run as a systemd service on Oracle Cloud. It watches a login-protected portal around the clock and emails me when a new item appears.

Refreshing a Page All Day

The task is trivial each time and exhausting in aggregate. That is exactly the kind of work software should take over.

Some web portals publish new items at unpredictable moments and offer no notification when they do. The only way to catch one is to keep a tab open and refresh it, again and again, for hours.

It fragments focus, eats the day and still misses things, because no person can refresh a page every few seconds without lapses.

  • Constant context switching just to check a page
  • Items missed whenever attention lapses
  • No record of what appeared, or when
  • The checker has to stay at a desk, awake

Watchtower takes that job over completely: watch, detect, tell me. Nothing more. What to do with an alert stays a human decision.

Boring on Purpose

Unattended software earns trust by being predictable. Watchtower was designed around four rules:

  • Observe only: it reports what it sees and never acts on the portal
  • Fail loudly, recover quietly: errors are logged, routine problems fix themselves
  • No duplicate noise: every item is reported exactly once
  • Secrets stay out of the code: credentials live in environment variables

Each rule removes a way for an unattended script to quietly stop being useful.

Lean, Linux-Native Stack

Few moving parts, all of them boring and well understood, running on a small cloud server.

Language
Python
Browser Automation
Playwright
Hosting
Oracle Cloud Infrastructure
Runtime
Linux + systemd
Alerts
SMTP email
Config & Logs
Environment variables + logging

How It Works

A simple loop with branching logic for expired sessions and repeat items.

Service starts
systemd launches Watchtower at boot and keeps it running as a background service.
Open a browser session
Playwright launches a browser and loads the portal like a normal visitor.
Check the session
Before reading anything, it confirms the login is still valid.
If the session expired
It signs in again automatically and carries on, with nobody needed to step in.
If valid
It moves straight on to reading the listing.
Extract the items
It reads the current listing and collects each item's unique identifier.
Detect what's new
Identifiers are compared with those already reported. Anything seen before is ignored.
If already seen
Ignored, so one item never triggers two emails.
If new
It is recorded and queued for notification.
Send the alert
An email goes out through SMTP with the identifier and context, so it reaches me wherever I am.
Log and repeat
The run is logged and the loop repeats. A hung browser is restarted, and systemd restarts the whole service if the process dies.

Built to Run Unattended

Anything that runs without a person watching fails differently from a script you run by hand. These behaviours are what let Watchtower keep going.

Session recovery
Authentication checks
Duplicate detection
Browser restart handling
Persistent execution with systemd
Structured logging
How it was built: I specified the behaviour, then used AI-assisted development to generate the code, reading, modifying and debugging it myself. The value was in the design: what to check, what can fail and how to recover.

What I'd Improve Next

A daily heartbeat email, so silence is never ambiguous
Push notifications alongside email
Back-off and polite polling intervals
A small dashboard of items seen over time

What This Taught Me

  • Unattended software fails in boring ways: expired sessions, stale browsers, network hiccups. Designing for those first matters more than the happy path.
  • Duplicate detection is what separates a useful alert from noise people learn to ignore.
  • Logging is the only window into a process nobody is watching.
  • Keeping credentials in environment variables is a small habit that avoids a large class of mistakes.

What This Demonstrates

Python automation built with AI-assisted development
Browser automation with Playwright
Linux deployment and service management on cloud infrastructure
Resilience design: session recovery, restarts and duplicate handling
Pragmatic, low-noise notification design

Common Questions

What is Watchtower?

Watchtower is a Python and Playwright monitor, deployed as a systemd service on Oracle Cloud Infrastructure, that watches a login-protected web portal and emails me when a new item appears.

What problem does it solve?

It replaces the habit of refreshing a page all day. Items that appear without any notification are caught and reported exactly once each, so nobody has to keep checking.

How does it keep running without supervision?

It confirms the session is valid before every read and signs in again if it has expired, restarts the browser if it hangs, ignores items it has already reported, and runs as a systemd service so the operating system restarts it if the process dies. Every run is logged.

Does it take any action on the portal?

No. It only observes and notifies. What to do with an alert stays a human decision.

How was it built?

I specified the behaviour and used AI-assisted development to generate the code, then read, modified and debugged it myself. Credentials are kept in environment variables rather than in the code.