A workout accountability partner, rewritten as a matcher, not a shortlist

No. vipassana.cool pairs people for a daily meditation sit, not a run or a lift. It is on this page because the matching primitives a workout partner app would need are the same ones this product already runs in production: a 60-minute circular UTC window, session-duration parity (15, 20, 30, 45, or 60 minutes), a prior-pair guard, and a 30-minute cron tick. If the reader is sitting 30 to 60 minutes a day and wants a real human in a Meet room at 6 AM, the pool fits. If the reader is looking for a gym buddy, it does not, but the shape of the matcher is still a useful reference implementation.

On 2026-04-23 the pool held 52 active rows (status pending or ready, morning_utc populated) across 47 distinct city strings and 19 declared timezones. The session-duration histogram was 21 at 60 minutes, 18 at 30 minutes, 5 at 20 minutes, 5 at 15 minutes, 3 at 45 minutes. 49 of 52 rows were 10-day course veterans (is_old_student = Yes). Running scripts/best-pending-pairs.mjs against that pool produced 23 non-overlapping viable pairs in a single tick. Every figure was pulled from the production waitlist_entries table on the day this page went live.

At src/app/api/auto-match/route.ts line 163 the matcher computes timeDiff(slotA.utcMinutes, slotB.utcMinutes) and drops the pair if the result exceeds 60. timeDiff is a circular minute distance: Math.min(|a-b|, 1440-|a-b|), so 23:30 UTC and 00:10 UTC are 40 minutes apart, not 1,400. Sixty is the operator's calibration for what a shared daily session still means. Thirty minutes starves the pool in most timezones. Two hours pairs 06:00 with 08:00 sitters and calls it the same session, which it is not. Sixty is the widest distance at which two adults in different parts of the world can plausibly dial into the same Meet at the same minute.

Four sort keys, strictly in order, no weights, no learned coefficients. First, readyScore: rows in status 'ready' outrank rows in status 'pending' (2 > 1 > 0 for sum of the pair). Second, bothOld: pairs where both rows have is_old_student = Yes outrank mixed or neither. Third, sessionMatch: pairs where the two rows declared the same session_duration outrank pairs where they did not. Fourth, the smallest UTC minute difference wins. Ties inside the fourth key are broken by iteration order, which is deterministic per tick. After the sort, a greedy walk picks non-overlapping pairs until every slot is either used or filtered out.

scripts/best-pending-pairs.mjs and auto-match both build a set of (person_a_id, person_b_id) tuples pulled from matches. Any candidate pair whose two ids are already in that set is dropped before scoring. The effect on the pool is monotone: every tick shrinks the viable subset for any given member, because the set of partners they have not yet been matched with can only decrease. This is not the behavior a Focusmate-style rolling booking wants; it is the behavior a daily-partnership product wants. Once two rows are matched, they are a committed pair, and the matcher will not quietly shuffle one of them off to somebody new tomorrow.

Because in the Goenka lineage the only fact that holds is whether a person has completed at least one 10-day residential course. Everything else (how many courses, how long they have sat, how many hours a day they sit now) is folk knowledge and does not correspond to a single verifiable checkpoint. The waitlist form asks is_old_student and stores 'Yes' or 'No'. A workout partner app could extend the same pattern with tiers (beginner, intermediate, advanced), but the failure mode of self-reporting would be identical, and the scheduler's sort key would still be a parity predicate, not a continuous score.

vercel.json schedules '*/30 * * * *' → GET /api/auto-match, so the matcher runs at :00 and :30 of every hour. Between ticks nothing happens in the database except fresh signups accruing and the 24-hour cool-off clock ticking forward for each pending row. A signup submitted at 09:15 is eligible at 09:45 only if more than 24 hours have passed, which they have not; the earliest the row can be matched is the next tick after it crosses its 24-hour anniversary. That cool-off is a content-quality gate: it gives the operator a full day to eyeball the signup before the matcher can pair it.

There is no dashboard check-in. When person A replies to the intro email, the ImprovMX webhook hits /api/webhooks/improvmx, advanceMatchOnReply() runs, and the match status moves from 'pending' to 'replied'. When person B replies, the same function sees an inbound from the other side in vipassana_emails and flips the status to 'active'. That is the weekly check-in. If neither side replies for 3 days the match is marked 'expired' by /api/expire-matches; if either side later declines the recurring Google Calendar invite, /api/check-rsvp catches it and flips the match to 'ended'. Nothing is a button. Everything is an email action the person was going to take anyway.

The architecture is portable, but this site is not it. A gym buddy matcher built on the same five primitives would need: (1) a waitlist form capturing timezone, session duration, experience parity, and cadence; (2) a scheduler at */30 minutes that enumerates pairs, applies a 60-minute UTC hard filter, and sorts by the parity keys above; (3) a prior-pair guard so you are not rematched with a partner who already ghosted; (4) an inbound-email state advance so the thread IS the check-in; (5) a permanent video room URL handed out once at match time. That is a usable reference implementation, but if the reader wants someone to spot them on a bench press, the matcher on this site is not the thing.

Honest answer: only if the reader counts a daily meditation sit as their workout. The pool currently skews 49 of 52 toward old students of the S.N. Goenka 10-day tradition, session durations cluster at 30 and 60 minutes, and every pair is for the same silent sit on Google Meet, not a shared gym session. If the reader is a meditator who has completed a 10-day course and is tired of sitting alone, the matcher is a near-perfect fit. If the reader is a lifter or a runner, the primitives on this page are genuinely useful but the pool is wrong, and a coach or a dedicated fitness app is the honest redirect.

No. Nothing on this page is operational instruction. The 10-day residential courses at dhamma.org are where the technique is transmitted by authorized assistant teachers, and this site only handles the logistics of peer pairing for daily sits after a reader has completed such a course. Any question about how to sit, how to work with a difficulty, what to notice, or how to structure a practice belongs in the course and with an authorized assistant teacher, not here.