Finding an accountability partner is surviving eight gates in one cron tick

It resolves to a waitlist_entries row reaching the bottom of a specific function without being filtered out. The function is the GET handler at src/app/api/auto-match/route.ts, lines 54 to 476. On each tick the handler loads rows, filters them, builds session slots, enumerates pairs, drops ineligible pairs, sorts, and writes matches. 'Finding' is the successful traversal of that pipeline for your row, at the tick where a compatible other row happens to survive the same filters. It is not a search you perform. It is a survival state your row is in, measured once every thirty minutes by the cron declared in vercel.json.

Eight. The first two are in the SQL of line 74: status must be in ('pending', 'ready'), and unsubscribed must be false. The third is the contact_count >= 10 check at line 84, which removes rows that have already been matched ten times without sticking; status 'ready' bypasses this. The fourth is the 24-hour cool-off at lines 88 to 90, which holds a fresh signup out of the pool for one day. The fifth is the 7-day retry cool-off at lines 91 to 102 for rows at contact_count between 1 and 9. The sixth is the UTC slot build at lines 108 to 122, which silently drops a row if toUtcTime cannot resolve its morning_time plus timezone into an HH:MM string. The seventh is the blockedPairs guard at line 160, which drops the pair when the two people have ever been in a confirmed or still-active match together. The eighth is the 60-minute hard filter at line 164: if timeDiff(a, b) is greater than 60 UTC minutes on the circular clock, the pair is discarded.

Because nothing outside the rows those predicates return can be 'found'. The SELECT on line 74 is the first thing the runtime does, and it picks a strict subset: status IN ('pending', 'ready'), unsubscribed = false. Rows with status 'matched', 'contacted', 'engaged', 'paused', or any other value are invisible to the cron. Rows with unsubscribed = true are invisible. Those are not cosmetic filters. They are load-bearing: the set the handler sees is the set the entire matching pipeline operates on. Counting them as gates one and two is the honest way to describe what it takes to be a findable row.

Line 49 defines timeDiff as `const d = Math.abs(a - b); return Math.min(d, 1440 - d);` where 1440 is the number of minutes in a day. That returns the shortest circular distance between two clock minutes. Line 164 reads `if (diff > 60) continue;`, which skips the pair. The practical effect is that 06:00 UTC and 07:00 UTC are 60 apart (pass), 06:00 and 07:01 are 61 apart (fail), and 23:30 and 00:15 are 45 apart (pass, because the distance wraps around midnight). This is why the page frames the window as circular rather than linear: a sitter at 23:45 UTC is still findable with a sitter at 00:30 UTC.

The blockedPairs set at lines 129 to 138 is built from every row in the matches table where at least one side confirmed the match, or the status is not in ('expired', 'declined', 'ended'). Then line 160 drops any candidate pair whose two IDs are in that set. The reason this is separate from 'same two people were matched before' is that it treats cold-bilateral-decline matches as unblocking: if neither side confirmed and the match ended, the pair can be retried against fresh conditions, but if either side confirmed at any point, or if the row is still live in any state, the same two will never be paired again automatically. The cron never reuses a partnership that got any real signal.

An email. The email is the only evidence the pipeline runs at all, because no UI shows the gate state in real time. If both rows happened to be 'ready' at the same tick, the intro email with a Google Meet link arrives. If one or both were 'pending' instead, a confirmation email arrives asking for bilateral opt-in before the Meet is created. Every other tick where your row did not survive all eight gates produces nothing for you. The cron writes its admin summary to the operator's inbox and goes quiet. Absence of an email is not a signal about you; it is a signal that the gates did not all align this tick.

Because most of the gates are exclusion predicates. contact_count >= 10 removes you. 24-hour cool-off removes you. Unsubscribed removes you. blockedPairs removes the pair. The predicate form is not 'you are findable because X' but 'you are findable unless X'. Writing it that way matches the code: if you list the reasons a row does not survive a tick, you have almost completely described the matcher. Frame the same thing positively and you would write nine conjoined conditions, which reads worse and describes the same behavior.

It stays pending and tries again on the next tick, 30 minutes later. The row is eligible, has a UTC slot, and has no blockedPair against any survivor in the current pool; it is just that nobody else's UTC minute is within 60 of yours at this instant. A twice-a-day sitter contributes two slots and so has two separate chances per tick. A new signup landing five minutes later could shift the pool inside the next tick. The row has no TTL and no escalating penalty. It is either matched on a future tick, or the reader updates their times and changes which distances are in range.

The admin page at /admin/matching surfaces the relevant fields and flow states for operators, but the raw cron has no per-row report. A transparent proxy is scripts/best-pending-pairs.mjs, which applies most of the same gates outside the request loop and prints every non-overlapping viable pair it finds in the pool at the moment it runs. Running that script on 2026-04-23 in the production repo produced 23 viable pairs. That script is good enough to show what 'your row survived the gates this tick' looks like without instrumenting the cron itself.

No. Nothing on this page is technique instruction. The S.N. Goenka tradition reserves transmission of the technique for authorized assistant teachers inside 10-day residential courses at dhamma.org. This site handles peer-pairing logistics only, and this page describes the filter gates in its scheduler. Any question about how to sit, how to work with a sensation, how to handle difficulty on the cushion, or how to structure daily practice goes to an authorized assistant teacher at a 10-day course, not here.