See which meetings are wrecking your sleep and recovery

Build me an app I open at the end of each week to understand how my meeting load is actually affecting my recovery. This is a retrospective analytics board, not a daily automation. Nothing runs on a schedule. I open it, look across the last twelve weeks, and figure out which meeting patterns are costing me sleep.

The main view is a table where each row is one day across the last twelve weeks. The left half of the row is meeting load computed from Google Calendar, using List Events. Show meeting hours, meeting count, longest uninterrupted gap and back to back count. Longest uninterrupted gap is the longest stretch of unbooked time inside my working hours, which should be a setting and default to 9am to 6pm in my calendar timezone. Back to back count is the number of adjacent meeting pairs separated by less than a configurable buffer, defaulting to five minutes.

When reading events, call List Events with singleEvents set to true so recurring series expand into individual instances, and keep the recurringEventId on each instance because the analysis step later needs to group instances back into their series. Page through with nextPageToken rather than assuming one response covers the window. Exclude all day events, which are the ones carrying a date instead of a dateTime, and exclude any event where my own attendee entry has a declined response status. Both exclusions should be visible toggles in the UI so I can turn them off and see how the numbers change. Use List Calendars to let me pick which calendars count toward meeting load, defaulting to my primary calendar, so subscribed and personal calendars do not pollute the math.

The right half of the row is recovery from Google Health. Show that night's sleep duration and sleep efficiency, read from List Data Points on the sleep data type, plus the next morning's resting heart rate and heart rate variability, read from Daily Roll-Up Data Points on the daily-resting-heart-rate and daily-heart-rate-variability data types.

Two fetching constraints matter and I want them handled properly rather than discovered at runtime. First, the closed-open range on the aggregation methods is capped at fourteen days, so a twelve week board has to page through the window in chunks of fourteen days or fewer and stitch the results together. Do not request twelve weeks in one call. Second, the sleep data type defaults and caps at a pageSize of twenty five, unlike the 1440 default on other types, so sleep reads must follow nextPageToken until the window is fully covered. Fetch the chunks in parallel where you can and show a progress indicator, since the first load spans a lot of requests.

Getting the day alignment right is the core of the whole app. A given day's meeting load pairs with the sleep session that began that night, meaning the session ending on the following morning, and with the resting heart rate and heart rate variability reported for that following morning. A Tuesday packed with meetings is judged against Tuesday night's sleep and Wednesday morning's heart numbers. Make this rule explicit in a tooltip on the table header so I trust what I am reading.

Give each day a single recovery index so the board can be sorted by worst recovery. Compute it by scoring sleep duration, sleep efficiency, resting heart rate inverted and heart rate variability against my own twelve week baseline rather than any population norm, then averaging them. Sorting by worst recovery is the default view and is the thing that surfaces the days that cost me most. Days missing health data should be marked as incomplete and sorted out of the way rather than scored as if they were good days.

Clicking a day expands it to show the actual meetings that ran that day, with title, time, duration and attendee count, alongside the sleep that followed, including the session start and end times and the efficiency figure. This is where I go to sanity check a bad row and see what really happened.

Add a Protect recovery time button that blocks time using Google Calendar Create Event. Let me pick the date, start time and duration, prefill a sensible default such as a ninety minute block, create it as a focus time event, and refresh the board afterwards so the new block is reflected. Confirm the details with me before creating anything, since this is the only thing in the app that writes to my calendar.

Add an Analyze this block button that kicks off a background agent over whatever date range I have selected on the board. The agent reads that range across both systems, using List Events for the meetings and List Data Points plus Daily Roll-Up Data Points for the sleep and heart metrics, respecting the same fourteen day chunking and sleep paging rules. It groups meeting instances by their recurring series, compares the recovery index of days containing each series against days without it, and writes a rebalancing recommendation back into the app naming which recurring meetings track with my worst sleep and what specifically to move, shorten or drop. Store each recommendation with its date range and timestamp, show it in a panel in the app, and keep the previous ones so I can see whether the advice changed after I acted on it. Show a clear running state on the button while the agent works, since it takes a while.

Cache fetched days so reopening the board does not refetch the entire twelve weeks every time, with a manual refresh control and a visible note of when the data was last pulled. Keep the framing throughout on understanding which meeting patterns wreck my recovery.