Daily sit accountability tracker: this site has three, and none of them records whether you sat

Why "tracker" is the wrong primitive after the first month

A digital tracker is a self-report surface with a memory. You sat. You tap a checkmark. The number goes up. After enough taps, the number is the thing you are protecting. That works while the gap between the act of sitting and the act of marking is small, which it usually is in the first thirty days. Motivation is high, the marking happens within minutes, the number describes the practice with reasonable fidelity.

What changes between day thirty and day three hundred is that the gap widens. A sit gets cut short and you mark it anyway, because partial credit feels honest. A morning gets missed and you mark the previous evening's sit twice, because the streak is a meaningful thing now. A travel day turns into a five-minute sit on a hotel bed and you mark a full session, because the alternative is a wound on the chart. None of these are dishonest in any ordinary sense. They are the small accommodations any self-reporting system gets, eventually, and they accumulate.

What you end up with at year two is a tracker that is internally consistent and externally untrue. The number looks like the practice but it is, in fact, a record of your relationship with the tracker. The Goodhart problem is general; it is not specific to meditation. The architecture on this site is one response to it. Do not measure the act. Measure something orthogonal, or measure nothing.

Surface one: a paper sheet at /daily-sit-log/print

The most tracker-shaped object on the site is a static page that prints to a single Letter sheet. It lives at /daily-sit-log/print. Twelve rows for the months. Thirty-one columns for the days. February is hard-coded to 29 cells so leap years render without a JavaScript date library. Each cell is a square split diagonally; the upper-left half is for AM, the lower-right is for PM. There are no numbers, no colors, no counts. The header has space for a name and a year. The footer carries four short rules and the URL of the site.

The four rules, verbatim from the file:

1. Mark after you sit, not before.
2. No colors. No metrics. No streak.
3. Missing a day is not failure. Stopping is.
4. Keep this page somewhere you will see it.

The whole page is 123 lines of TypeScript at src/app/daily-sit-log/print/page.tsx. It is a static layout component with no API call, no analytics event, no auth, no user model, no database row. The URL is the entire interface. You print it once, you mark it with a pen, and the file knows nothing about your practice. Whatever marks land on the paper land in your drawer, not in a server. The deliberate absence of digital state is the point. Compared to every app in the standard shortlist, this surface gives up the one feature that makes a tracker a tracker: persistence and aggregation across devices.

Surface two: a 16-line day counter that reads from a constant

The number that appears in several places on this site (964+ days as of writing) does not come from a streak the user is responsible for keeping intact. It comes from one file, sixteen lines long, that defines two constants and subtracts a date.

The file is src/components/day-counter.tsx. BASE_COUNT is set to 881. REFERENCE_DATE is set to 2026-02-07. When the component renders in a browser, it reads the system clock, computes the difference in whole days between the current date and the reference date, adds the base count, and renders the integer followed by a plus sign. There is no API call, no authenticated user, no stored streak. There is also no streak-break logic, no pause, no excused-absence flow, no make-up-day primitive, no celebrate-milestone modal, and no notification when the number changes.

The number describes one specific person's practice (mine, since the day after my third 10-day course at Dhammamanda in NorCal) and it is not your tracker. You cannot pause it, you cannot reset it, you cannot share it, you cannot earn a badge from it. It is closer to a clock than to a tracker. It ticks. The deliberate small surface is the editorial decision: a practice number that the surface producing it cannot lie about.

A reader can verify the math. Open the file, copy the constants, and run the subtraction by hand. The number on the homepage will agree with your arithmetic to the day. That is the entire claim the surface makes. It does not claim to know about your sits, because it does not.

Surface three: a daily cron that tracks calendar RSVP, not sits

The third surface is the one that looks the most like a tracker from the outside, and the one whose mismatch with the word "tracker" is most useful to walk through. It is a cron at src/app/api/check-rsvp/route.ts, 192 lines. It runs daily. For each active match in the database, it fetches the corresponding Google Calendar event, reads the attendees array, finds person A and person B by email, and records their responseStatus into two columns on the matches row: calendar_rsvp_a and calendar_rsvp_b. If either person's responseStatus is the string "declined", the cron flips the match status to "ended" and stops scheduling either of them with each other.

What the cron does NOT track:

• Whether either person joined the Google Meet link this morning.
• Whether either person stayed on the call for the full sit duration.
• Whether the call rang into an empty room and one person left after a minute.
• Whether either person sat at all (cushion presence is invisible to the calendar).

The cron tracks one thing: the binary state of "have you revoked your acceptance of the recurring meeting". Everything else is invisible to it. A sit that happened in silence with both people on the Meet looks identical, in the database, to a sit that nobody attended. The system intentionally cannot tell the two apart.

The shape of the polling pass, end to end, looks like this:

The asymmetry is clear in the diagram. Every arrow that touches Calendar reads or writes RSVP state. None of them read or write a sit-completion event. Calendar does not have a sit-completion event to read.

The schema check: zero columns for sit completion

If the system did track sit completion anywhere, the column would live in src/lib/db.ts. That file is 542 lines. Two tables matter for this page: matches and waitlist_entries. Matches stores the pairing between two practitioners. Waitlist_entries stores the unmatched roster.

A grep over that file for words a sit-completion field would plausibly use:

The matches table tracks: id, person_a_id, person_b_id, person_a_session, person_b_session, status, created_at, notes, person_a_token, person_b_token, person_a_confirmed, person_b_confirmed, declined_by_id, calendar_event_id, calendar_rsvp_a, calendar_rsvp_b. That is the full list. A reader can clone the repo and grep the same words and get the same result. The absence is verifiable.

The argument: separate tracking from accountability, then drop the tracking

The phrase "daily sit accountability tracker" compresses two distinct functions into one object. Tracking is the recording. Accountability is the consequence. Most apps in the standard shortlist provide both inside the same surface: the streak record IS the consequence, because breaking the streak is what stings.

This site separates the two. Accountability lives in the matching service: a Google Calendar event with another old student, recurring on RRULE:FREQ=DAILY, with a Meet URL that auto-creates via the Calendar API's createRequest field. The consequence of skipping is a specific empty room with a specific other person on the other side of the link. That consequence does not depend on a tracker. It happens in real time, between two people, with no dashboard either of them can open.

Tracking, separately, is reduced to two surfaces neither of which records the act of sitting: a paper sheet that you mark with a pen if you want, and a homepage day counter that describes one practitioner's practice from a constant. The first is private to your drawer. The second is not yours. Neither is connected to your partner. Neither is connected to a database. Neither fires a notification when you skip.

At year three, the architecture left standing is the one that never wove tracking into the accountability layer. The two functions are doing different jobs and they sit on different surfaces. When the tracking gets unreliable, which it does, the accountability layer is still intact, because it never depended on the tracking to begin with.

A short note on the first month

None of the above argues against using a streak app in the early phase of a daily practice. In the first thirty days, a streak is a useful proxy and the gap between the act of sitting and the act of marking is small. If the standard shortlist of apps gets a beginner from day one to day forty, that is a real outcome and the apps deserve credit for it.

The argument is a year-three argument. By then, motivation is gone and the tracker is doing other work. The system that survives that transition is the one that never put tracking and accountability on the same surface. That is the entire point of three trackers that do not track the sit.