Automating a Daily Task Instead of Repeating It

This project started with a small but annoying observation. A daily business workflow depended on someone manually opening a website every morning just to check updated prices.

It was repetitive. Easy to forget. And clearly automatable.

So I automated it.

The Problem

Every day, the same steps:

• Open a website
• Find today’s price
• Read the numbers
• Share them with others

Nothing complex. Just fragile human effort.

I didn’t want dashboards. I didn’t want alerts, logins, or subscriptions.

I wanted the system to:

• Run every day
• Fail safely
• Never need babysitting

The Solution

I built a small Python automation that runs on its own.

The script:

• Sends an HTTP request to a public website
• Parses the returned HTML
• Locates the table containing the Pune egg rates
• Extracts only today’s row
• Reads values for piece, tray, 100 eggs, and peti

Because websites change, the script is defensive by design.

If:

• Today’s data isn’t present, or
• The page structure changes

It does not guess. It fails cleanly and sends a clear “data unavailable” message instead of incorrect numbers.

Wrong data is worse than no data.

Delivery, Not Just Extraction

Once the data is extracted, it’s formatted into a simple, readable message.

That message is sent automatically using the Telegram Bot API.

The same message is broadcast to multiple recipients:

• No duplicated logic
• No separate flows
• No per-user handling

Simple input. Simple output.

Full Automation with GitHub Actions

I didn’t want this tied to my laptop.

The entire workflow runs via GitHub Actions on a scheduled cron job.

Every day, the workflow:

• Spins up
• Installs dependencies
• Runs the script
• Exits

All sensitive values — bot token and recipient IDs — are handled through environment variables and GitHub Secrets. No secrets in code. No shortcuts.

Intentional Simplicity

This project was deliberately minimal.

No:

• Database
• Backend server
• Frameworks
• Paid services

Just:

• Python
• HTTP
• HTML parsing
• A scheduler
• A messaging API

The focus wasn’t showing off complexity. It was building something reliable, understandable, and cheap to run.

Once deployed, the system requires zero manual intervention, zero maintenance, and zero daily thought.

It just works.

What I Learned

This project reinforced a simple but important idea: small systems that solve real problems teach you more than large systems built for demos.

I improved my understanding of:

• Web scraping
• Defensive programming
• Automation
• Designing systems that expect failure instead of ignoring it

No buzzwords. No overengineering. Just removing friction from real life.

And that’s usually the best place to start.