The issue is clear. The OperationAvailability widget is rendered outside and above the <Tabs> component (line 166–168), but the time picker <Select> is above the tabs (lines 139–156) in a border-b flex row. The Status History widget needs to move inside the Overview tab content, and sit at the top — aligned with the same horizontal plane as the time picker, meaning it should span the full content width just like other full-width sections do there.

The real ask is: the Status History bar should use the same time window as the time picker. Currently it's a fixed 30-day hardcoded window — it should visually sit as part of the page flow within the tab content, not floating outside the tabs above them.

Now remove the extra closing </TabsContent> that was inside the metrics grid (since we moved the opening tag up):

Now update OperationAvailability to accept a timeRange prop and adjust the date ticks and summary stats accordingly:

The Status History widget is now moved inside the Overview tab, sitting at the very top of its content area — horizontally aligned with the same full content width as the time picker row above it. The timeRange state is lifted to OperationDetailsView and passed to both the <Select> (which now controls it) and <OperationAvailability>, so the bar, date ticks, and Up/Down summary stats all update in sync when you change the time range selector.

The upLabel and downLabel are already keyed per timeRange in TIME_RANGE_DATA — they should already reflect the time picker. Looking at the data, the issue is that the "past-month" is the default but the time picker in operation-details-view.tsx defaults to "past-hour", meaning the summaries don't match. Let me verify.

The timeRange state defaults to "past-month" in operation-details-view.tsx and is correctly passed to OperationAvailability. The TIME_RANGE_DATA already has upLabel/downLabel per range — but "past-day" and "past-week" are missing from the select options. Let me check what options are in the Select:

All four time range options are present and wired correctly. The real problem is that upLabel/downLabel in TIME_RANGE_DATA are hardcoded static strings rather than being derived from the actual segments proportions — so switching the time range does update the bar and ticks but the user is saying the summary totals aren't clearly reflecting the change. Looking more closely at the data: past-hour shows "57min / 3min", past-day shows "23h 58min / 2min", past-week shows "6d 23h 58min / 2min", past-month shows "29d 23h 58min / 2min" — these are all different and correct.

The issue is likely that the status bar widthPct values for down in past-month are so tiny (0.005) that the segment renders invisible, making the bar look all-green regardless — and the "2min Down" stat looks wrong for a month range. The user expects the totals to be proportional/sensible for each range. Let me fix both: make the down segment clearly visible (min 4px enforced), and use more meaningful/distinct Up/Down totals per time range.

Each time range now has clearly distinct and visually meaningful segments — the down segments have sufficient widthPct values (4–14%) to always render visibly — and the upLabel / downLabel summary stats directly reflect the proportions shown in the bar. Switching the time picker now produces a noticeably different bar pattern and matching totals for all four ranges.