# Reminder Health: What My Apple Reminders Data Says I wanted a better sense of the health of my reminder system, not just a list of tasks. The goal was to understand a few questions that are hard to answer by simply opening Apple Reminders: - How many reminders am I creating over time? - Am I completing reminders at roughly the same pace that I create them? - How quickly do reminders get completed after I create them? - Once reminders are created, how often do I actually modify them? - How concentrated are my reminders in a few lists versus spread evenly across the system? To answer those questions, I used Python with PyObjC/EventKit to query all of my reminders programmatically and generate a small set of graphs. ## Why I Use Reminders in the First Place My reminders workflow has a long arc. - In middle school, Ms. Flint had us use an agenda and said the human brain can only hold around seven things at once. - Later, Don Winkler (former CEO of Ford Finance) reinforced the habit and pushed me to use reminders more systematically. - At Georgia Tech, working with Thad Starner deepened this idea through wearable-note workflows and always-available capture. - At Microsoft, the mission to help every person on the planet achieve more sharpened this into a personal chain: idea -> thought -> action -> retrieval. That chain matters to me because achievement starts with remembering what was worth acting on after the moment of idea creation passes. TODO: Add a citation/link for the Thad Starner everyday wearable-computing paper and note format (latest notes first / reverse-chronological ordering). ## Weekly Reminder Activity: Created vs. Completed The first chart tracks weekly reminder creation and weekly reminder completion as two separate lines. ![Weekly reminders created vs completed](reminder-health-dashboard-assets/reminder-health-weekly-created-vs-completed-20260614.png) This is a more useful operational graph than a simple count of total reminders because it shows flow rather than inventory. A few things matter here: - Creation and completion are different events and should be tracked separately. - A healthy system should not just create reminders, it should also close them out. - Spikes in creation rate can indicate brainstorming sessions, shopping/list capture, or project planning bursts. - Spikes in completion rate can indicate cleanup sessions or the closing of many short-lived reminders. One important piece of context for the early part of the graph: the first few weeks were likely a testing period where I was trying Apple Reminders to see whether I actually liked it before fully committing. During that initial phase, both reminder creation and completion stayed fairly low because I was just experimenting with the system rather than fully living in it. Then the first major creation spike was likely not organic weekly reminder growth at all. It was most likely the period when I migrated reminders from Google Reminders into Apple Reminders, which is why the July spike is so pronounced. That migration mattered because Apple Reminders has much tighter integration with the hardware I actually use day to day, especially Siri and Apple Watch. In practice, that means reminder capture became much easier through voice and quick device interactions. So the spike is partly a data migration event and partly the beginning of a workflow shift toward a system that is easier to feed in real time. At the current snapshot used for this analysis: - Total reminders created in the dataset: 2,066 - Total completed reminders in the dataset: 1,204 - Current incomplete reminders: 862 - Average reminders created per week: 19.0 - Average reminders completed per week: 11.1 - Average reminders created per month: 79.5 - Average reminders completed per month: 46.3 ## Time to Completion: How Fast Do I Finish Reminders? The next chart looks specifically at time to completion: the number of days between creating a reminder and completing it. ![Reminder time to completion](reminder-health-dashboard-assets/reminder-health-completion-latency-20260614.png) This answers a different question from reminder modification. A reminder can sit untouched but still be completed quickly, or it can be edited many times before completion. The current distribution suggests a mixed system: - Median completion latency is about 15 days. - 90th percentile completion latency is about 253 days. - There are 51 reminders in the current dataset that took more than 400 days to complete. That means many reminders are getting completed on a reasonable timescale, but there is also a real long tail of reminders that linger for months or even years. The interesting part is what those long-tail reminders actually are. They are not all one kind of task. A few of them are: - old idea reminders that eventually became irrelevant, - event or outing ideas that were never going to happen, - gear or shopping reminders that stayed around forever, - and recurring operational reminders like rent that were being used more as placeholders than as one cleanly closed task. Examples from the 400+ day tail: - `Spotify keep lyrics permanently up 📅` — 704 days - Spotify eventually shipped a version of this behavior slowly enough that the reminder sat around for a long time. - Reference link from the original reminder notes: https://community.spotify.com/t5/Live-Ideas/Your-Library-Keep-lyrics-up-at-all-times/idi-p/5523161# - [`Tractor tavern music (Indy / folk)`](./music-shows-serendipity-and-custom-band-shirts.md) — 704 days - This one lingered because it took a while for an artist I actually liked to play there. - The artist that eventually performed there was Sports, and the concert was epic. - To do: include a photo. - `World Cup 2026 - Seattle / Miami / Atlanta - too expensive` — 668 days - `Black socks for work` — 635 days - [`Get shorter lines for better photos`](./kitesurfing-shorter-lines-better-photos.md) — 580 days - This is about kitesurfing. - `Woodland park zoo` — 562 days - `Date in downtown Seattle w/ flowers from pike place` — 529 days - Valerie and I did go on a few dates in Seattle, but I likely forgot about this one or just did not see it for a while. - To do: include a photo. - [`AC repairs - see exact estimates from Ballard auto shop`](./car-repairs-ownership-and-when-to-sell.md) — 501 days - Part of why this one mattered was the large financial cost tied to the repair decision. - I ultimately sold that car and the Nissan Xterra and replaced them with my Bronco. That is useful because it suggests the long tail is not just procrastination. Some of it is really stale intent, outdated context, or reminders being used as parking spots for ideas that should maybe live somewhere else. This long tail is probably where reminder hygiene matters most: - some reminders should be completed, - some should lose their due date, - some should move to a better list, - and some should leave Reminders entirely and become notes or project material elsewhere. ## Modification Latency: How Often Do I Revisit Reminders? I also wanted to measure how often reminders get modified after they are created. This is not the same as completion speed. It is really a measure of how much lifecycle activity a reminder has after creation. ![Reminder lifecycle distribution](reminder-health-dashboard-assets/reminder-health-lifecycle-distribution-20260614.png) Because long tails can compress the early part of the distribution, I also generated a zoomed-in version for the first 50 days. ![Reminder lifecycle distribution 0 to 50 days](reminder-health-dashboard-assets/reminder-health-lifecycle-0-50-days-20260614.png) The main takeaway is that a large share of reminders are not being heavily revised after creation. In other words, many reminders are created and then either completed quickly or left mostly alone. From the current snapshot: - 29.1% of reminders show less than 1 day between creation and last modification. - 45.1% are within 7 days. - 65.2% are within 50 days. That suggests my reminder system behaves more like a capture-and-close system than a frequently edited project management system. The reminder is often born close to its final shape. After it is created, I usually do not keep refining or rewriting it. ## Stale Incomplete Backlog by Age To isolate unfinished backlog pressure, I also plotted incomplete reminders by age bucket (creation date to now). ![Stale incomplete reminders by age bucket](reminder-health-dashboard-assets/reminder-health-stale-incomplete-age-buckets-20260614.png) This shows where unfinished reminders accumulate over time and makes it easier to decide which buckets need aggressive cleanup versus periodic review. ## Distribution Across Lists The final chart looks at how reminders are distributed across lists, split by completed versus incomplete. ![Reminder distribution by list](reminder-health-dashboard-assets/reminder-health-list-distribution-20260614.png) This is useful because reminder overload is not always global. Sometimes the issue is that one or two lists absorb most of the system's clutter. This graph helps identify: - where backlog accumulates, - which lists are mostly archival/completed, - which lists are actively operational, - and whether the list taxonomy itself is doing useful work. A healthy reminder system probably does not mean that every list is balanced. It more likely means that each list has a clear role and that the incomplete reminders in that list are the ones that actually deserve attention. One immediate takeaway from the current snapshot is that the default `Reminders` list still dominates the system: - `Reminders`: 598 total - 48 open - 550 completed That is exactly what I would expect from the historical workflow. Assigning a reminder to the right list inside the Apple UI takes a few extra clicks, so the default bucket naturally becomes the landing zone for fast capture. That is starting to change. Now that an agent can move reminders in bulk and sort them into the right categories programmatically, the friction is much lower. Over time, I would expect fewer reminders to accumulate in the general `Reminders` list and more of them to live in the domain-specific lists where they actually belong. ## Metadata Coverage (Notes, URLs, Priority, Alarms) I also ran a metadata-richness pass to see which reminder features I actually use. ![Reminder metadata richness](reminder-health-dashboard-assets/reminder-health-metadata-richness-20260614.png) From this snapshot: - Total reminders: 2,066 - With notes: 397 - With priority: 80 - With any URL: 208 - URL field set directly: 0 - URL present in notes text: 208 - With alarms: 61 The important interpretation is that URL usage is real, but it mostly lives inside notes rather than EventKit's dedicated URL field. ## What This Suggests About Reminder Health If I had to summarize the current system in plain language: - I create reminders in bursts. - I do complete a substantial number of them. - Many reminders are completed or touched soon after creation. - A long tail of reminders survives for a long time. - The system is split across many lists, which is good for categorization, but it also creates the possibility of stale items hiding in specialized lists. This is exactly the kind of system that benefits from a [reminder-health dashboard](./smart-home-dashboards-and-domestic-control-planes.md). The next version of this analysis should probably add: - overdue counts by list, - reminders that should lose their due date, - estimated time to complete for each reminder or reminder class, - and maybe a score for list hygiene. The important part is that Apple Reminders already contains the metadata needed for this analysis: title, list, completion state, priority, due date, notes, creation date, and last modified date. Once those fields are available programmatically, the reminder system becomes measurable rather than just visible. ## What Comes Next: Optimization The natural follow-on to measurement is prioritization. Beyond the dashboard, the next layer of this project is a deterministic scorer that recommends the next N reminders to actually complete. The input signals are: - **Due pressure** — signed days from now (negative means overdue, positive means upcoming, absent means no due date) - **Estimated time** — how long the task takes in minutes, annotated in notes as `est_time: 30m` - **Estimated cost** — financial stake in the task, annotated as `est_cost_usd: 45` - **Priority** — the existing Apple Reminders priority field (none / low / medium / high) - **Estimated value** — a 1–10 importance score, annotated as `est_value: 7` The three annotation fields (time, cost, value) are set by an LLM agent when creating or reviewing a reminder. The scorer then runs deterministically on that structured data. The algorithm is a **multi-dimensional knapsack greedy approximation**. Because deadlines are generally soft rather than hard, EDF and deadline-based schedulers do not fit. The real problem is: given a time budget and a cost budget, select the subset of reminders that maximizes total value. That is exactly the multi-dimensional knapsack formulation. The greedy approximation sorts by value density (composite score divided by estimated time) and accepts items until either budget is exhausted, running in O(N log N).