Online accountability partner: the ±60 UTC minute cap that decides who can actually be in the room with you

It means one specific thing: the pair can share a single Google Meet URL at a time that both of them have already told us is a realistic hour of their local day. The mechanism is a single line in src/app/api/auto-match/route.ts (line 164): if (diff > 60) continue. That diff is the distance in UTC minutes between your preferred sit time and theirs, wrapped across midnight, so a 23:58 UTC start is 4 minutes from a 00:02 UTC start, not 1436. Anyone more than 60 wrapped UTC minutes from you is filtered out of the candidate pool before the ranking sort ever runs. Distance in miles is not part of the calculation at any point. The only geography that matters is the UTC offset your IANA timezone produces right now (DST-aware via Intl.DateTimeFormat at src/lib/db.ts lines 68 to 77).

60 is the upper bound at which two people can both agree 'we are sitting in the morning' and both be telling the truth about their own clock. A sit-at-06:00-Pacific person and a sit-at-07:00-Central person are 60 minutes apart in local time, 0 minutes apart in UTC, and this works. A sit-at-06:00-Pacific person and a sit-at-07:00-Eastern person are 60 minutes apart in UTC, and this also works because both have anchored their lives around 'morning'. Above 60 UTC minutes, one of the two is sitting in what, by any honest definition, is their afternoon or evening — the online pairing would be a recurring calendar event that cuts one person's day in half. The cap is the engineering expression of that constraint. Shorter windows (30 min) would starve the pool; longer windows (120 min) would produce pairs that fall apart within a week because the 'partner' is actually someone eating lunch while you meditate.

The store keeps each person's IANA timezone string (America/Los_Angeles, Europe/London, Asia/Kolkata) plus a local morning_time and optional evening_time. The derived morning_utc and evening_utc columns are not trusted at match time. On every cron run (every two hours) the matcher calls toUtcTime(person.morning_time, person.timezone) fresh for both people — defined at src/lib/db.ts lines 80 to 86 — which re-asks Intl.DateTimeFormat for the shortOffset of that IANA zone right now. That means the day the US springs forward and the day London springs forward (a two-week gap most services get wrong), the UTC window of every affected person moves with their clock, and the matcher's 60-minute filter operates on post-DST truth. No cron job rewrites rows; the read path recomputes every time.

Yes, sometimes, for a while. Someone in the middle of the Pacific at 03:00 UTC with a very early sit, or someone in a Himalayan mountain timezone that happens to be empty in the candidate pool this hour, can sit through two or three matcher runs without a viable pair. The handling is honest: the row stays in waitlist_entries with status='pending' and contact_count=0, and the every-two-hours cron keeps trying. There is no fake pairing to a timezone-incompatible person. The operator (me) gets an admin email at the end of every run showing 'pool: N, sessions: M, eligible: K' and the number of viable pairs produced, so stranded rows are visible. If a rare timezone is stuck for days, the operator reaches out by hand and asks whether a morning or evening slight-shift is possible.

Rows in the meet_clicks table. Each partner has their own /meet/<uuid-token> tracking URL that was emailed to them in the intro, put on their calendar invite, and is what they actually click every morning. The GET handler at src/app/meet/[token]/route.ts does one INSERT INTO meet_clicks (token, match_id, person_id, meet_url, ip, user_agent) and then a 302 redirect to the shared Meet URL. So the daily performance signal is two rows, same match_id, within a few minutes of each other. One row without a partner row is the partial-performance signal; zero rows over several consecutive days is the silent-breakup signal that the operator closes manually. There is no streak counter, no XP, no check-in button, no 'did you meditate?' prompt. The click is the receipt.

Possible but fragile. The click-to-redirect flow takes the person to a real Google Meet URL that has their partner's Google Calendar email on the attendee list. If neither actually joins the Meet, the other's meet_clicks row still lands but the other person also sees an empty room and notices. Two or three mornings of that and the human on the other side stops clicking too, which the ongoing-silence detector catches and ends the pair. The system is not designed to prove attendance the way an online exam would — it is designed to give both people a shared Meet URL and a shared calendar, and let the social cost of a missing partner do the work the literature on peer accountability says it does. The point of 'online' here is the shared room, not the proctor.

Yes, and that is actually the easy case. Two people in New York with morning sits 15 minutes apart have a UTC diff of 15, comfortably inside the cap, and the matcher pairs them on the same flow as a New York / London pair with a UTC diff of 55. There is no 'local-only' vs 'cross-country' branch in the code. Online here is indifferent to geography below the 60-minute UTC threshold. Once a week sit-together in person is fine too, for pairs that happen to be in the same city; the product does not know about it and does not need to, as long as the daily Meet URL continues to get clicked.

A few Postgres reads on waitlist_entries, matches, and meet_links; two Resend email sends for the intro or confirmation flow; one Google Calendar API call to create the recurring event; and one insert into meet_clicks per person per day thereafter. There is no LLM inference, no vector search, no embeddings, no WebRTC infrastructure (Google Meet handles all video), no custom app, no push-notification service. This matters for 'online' specifically because the cost to maintain an active pair is bounded by the infrastructure the users already use — Gmail, Calendar, Meet — rather than a proprietary stack.

One edge: Pacific/Kiritimati (UTC+14) paired with Pacific/Niue (UTC-11) gives a 25-hour offset. In raw local-clock diff this is nonsense, which is why the matcher converts both to UTC first, applies the modulo-1440 wrap in timeDiff at lines 49 to 52, and measures the shorter arc around the clock. For that specific pair, a 06:00 local sit in Kiritimati is 16:00 UTC and a 07:00 local sit in Niue is 18:00 UTC — a 2-hour (120-minute) gap, above the cap. So they would not match on morning sits, but their evening sits might. This is the kind of thing the 1440-minute wrap makes possible to reason about cleanly. A naive subtract would have them 25 hours apart, which is meaningless.

This site does not teach the practice and will not. Goenka-style Vipassana is transmitted at 10-day residential courses by authorized assistant teachers through dhamma.org on a strict donation basis. If you are new, register for a 10-day course there, take the course, then come back if you want an online partner for your daily sits. If you are already a student and have a technique question, write to your assistant teacher or to the nearest centre. The /practice-buddy flow on this site exists for the specific narrow case of two already-practicing meditators wanting a daily Meet URL in their calendar; it is not an alternative to going to a course.