CoWaiting monitors availability across popular colivings and sends email alerts when rooms open up.

Genesis

I discovered colivings in 2021. The popular ones were booked months in advance. After weeks of manually checking for cancellations, I built a program to notify me when spots opened.

Friends wanted these notifications too, so I made it public in March 2023.

Features

• Notification filtering: Users subscribe for specific periods and rooms, avoiding unwanted alerts.

• Constant monitoring: Availability is checked every 10-20min across 20+ colivings.

• Public calendar: Added February 2024. Shows availability for each coliving (some↗ colivings↗ embed this calendar instead of their booking system’s).

• Multi-room stay suggestions: Added January 2025. Suggests potential stays if guests are open to switching rooms. Coliving guests stay 2+ weeks on average and are flexible about room changes—something booking engines don’t support well.

Impact

At the time of writing (June 2025), there have been 2,200 subscriptions and 1,200 unique users. All through word-of-mouth: guests tell other guests, but mostly coliving operators link to CoWaiting, embed it, and suggest it to inquirers.

CoWaiting fixes an inefficiency: Coliving operators get a reduced import of cancellations and better occupancy without maintaining waiting lists, while coliving guests get to learn about availability first.

Implementation

I built CoWaiting on Cloudflare Workers↗ for three reasons:

• I wanted to learn their stack – this was my first serious Workers project.
• I wanted to avoid server maintenance since I run this project for free.
• Frequent scraping works better with varied IPs from Cloudflare’s cron jobs. (I try my best to make the scrapers polite, and several booking engines now explicitly allow the scraper.)

Architecture

• Cloudflare D1: Database for subscriptions and scraping data.
• Cloudflare KV and R2: Storing availability snapshots.
• Cloudflare Queues: Messages between workers.

The service is slightly over-engineered (for learning purposes) and operates on 7 workers:

• scraper: Runs a cron job that scrapes the availability. Any changes trigger the notifier (through a message).
• notifier: Extracts the changed periods and rooms, matches them to subscriptions (if any) and sends email messages to the mailer.
• mailer: Attempts to deliver email messages, and retries on failure.
• logger: Sends logs to a Matrix channel, including every booking/cancellation event and number of notifications sent. Helps me check the service is running correctly.
• frontend: Hosts cowaiting.net↗, a mostly-static Next.js website.
• api: Used by the frontend.
• interval-tracker: Maintains a graph of related bookings and cancellations. It’s used to list the latest cancellations, and detect whether they have been booked.

Scraping

The scraper can currently extract availability from the booking engines of Sirvoy, BookingLayer, Mangobeds, HBook, FrontDesk Master, or alternatively from an iCal feed. In some cases the data is scraped from an API, but often it’s extracted from HTML.

When I built it, I thought maintaining the scrapers would be the toughest job, but 2 years later, I’ve only had to update a scraper once. These systems rarely change – it’s partly why I started building Pingotel.