fix(usage): key the chart to the calendar the query grouped by

Three review findings, all real.

Densification walked UTC dates while `readUsageTimeSeries` groups by
`date_trunc($bucket, created_at AT TIME ZONE $timezone)` — the viewer's calendar.
For a non-UTC viewer the edge buckets never matched, so their cost stayed in the
headline while their bar read zero. Week and month were worse: Postgres aligns
those to Monday and the 1st, so a cursor stepping from an arbitrary period start
shared no key with the query at all and the whole chart came back zeroed against
a correct total. That is reachable today through an annual enterprise period,
which resolves to `week`.

`densifyUsageSeries` now takes the timezone, derives its first and last bucket
through `Intl.DateTimeFormat('en-CA', { timeZone })`, and truncates both to the
bucket boundary so the keys are the ones `date_trunc` emits. Stepping stays civil
`YYYY-MM-DD` arithmetic — UTC as a proleptic calendar, never converted back to an
instant, so no DST transition can shift a bucket.

The custom-range picker passed `showTime`, so it serialized its end bound as an
inclusive `…T23:59:59` local wall time; the resolver then added a further day.
Every custom range covered 24 hours too many, a legal 92-day selection measured
93 and was rejected, and the wall-clock string parsed as local while the rest of
the window logic is UTC. Dropped `showTime`: a time of day is precision a
day-bucketed panel cannot render, and bare `YYYY-MM-DD` bounds parse as UTC
midnight, which is what makes the half-open `+ DAY_MS` correct.

Admin organization provisioning answered 500 for state it had already committed,
and the existing-membership check then blocked the retry, leaving an organization
no workspace could reach. Attachment is a follow-on effect, not part of creating
the organization, and it is deliberately not folded into the creation
transaction: it runs its own under a lock order that exists to avoid deadlocking
against invitation acceptance, and re-deriving that in a route is how a deadlock
ships. Its failure is now caught and logged, and the endpoint returns the
organization it created.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: icecrasher321

apps/sim/app/api/v1/admin/organizations/route.ts

@@ -25,6 +25,7 @@ import { AuditAction, AuditResourceType, recordAudit } from '@sim/audit'
 import { db, dbReplica } from '@sim/db'
 import { member, organization, organizationColumns, user } from '@sim/db/schema'
 import { createLogger } from '@sim/logger'
+import { getErrorMessage } from '@sim/utils/errors'
 import { slugify } from '@sim/utils/string'
 import { count, eq } from 'drizzle-orm'
 import {
@@ -162,13 +163,34 @@ export const POST = withRouteHandler(
        * one exists. Creating a workspace only closes that gap once the organization
        * carries a usable Team/Enterprise plan; without one the creation policy still
        * resolves to a personal workspace.
+       *
+       * Attachment is a follow-on effect, not part of creating the organization, and
+       * it is deliberately not folded into the creation transaction: it runs its own,
+       * under a documented lock order (invitation scope, then organization, then
+       * workspace rows) that exists to avoid deadlocking against invitation
+       * acceptance. Re-deriving that ordering in a route is how a deadlock ships.
+       *
+       * So its failure must not be reported as a failure to create: the organization
+       * is already committed, and answering 500 for state that exists left the retry
+       * blocked by the existing-membership check above, with no way to reach the
+       * organization at all. Log it and return the organization that was created —
+       * attaching a workspace afterwards is a normal, repeatable operation.
        */
-      const { attachedWorkspaceIds } = await attachOwnedWorkspacesToOrganization({
-        ownerUserId: ownerId,
-        organizationId,
-        externalMemberPolicy: 'keep-external',
-        includeArchived: true,
-      })
+      let attachedWorkspaceIds: string[] = []
+      try {
+        ;({ attachedWorkspaceIds } = await attachOwnedWorkspacesToOrganization({
+          ownerUserId: ownerId,
+          organizationId,
+          externalMemberPolicy: 'keep-external',
+          includeArchived: true,
+        }))
+      } catch (attachError) {
+        logger.error('Admin API: Created organization but could not attach its workspaces', {
+          organizationId,
+          ownerId,
+          error: getErrorMessage(attachError),
+        })
+      }
 
       const [createdOrg] = await db
         .select(organizationColumns)

apps/sim/ee/organization-usage/components/usage-monitoring.tsx

@@ -261,9 +261,17 @@ export function UsageMonitoring({ organizationId, workspaceId }: UsageMonitoring
           >
             <PopoverAnchor className='pointer-events-none absolute inset-0' />
             <PopoverContent align='end' sideOffset={4} className='w-auto p-0'>
+              {/*
+                No `showTime`: the panel buckets by calendar day, so a time of day is
+                precision it cannot render. It also emitted the end bound as an
+                inclusive `…T23:59:59` local wall time, which the window resolver then
+                treated as a midnight and pushed a further 24h — every custom range
+                covered an extra day, and a legal 92-day pick measured 93 and was
+                rejected. Bare `YYYY-MM-DD` bounds parse as UTC midnight, matching the
+                rest of the window logic.
+              */}
               <Calendar
                 mode='range'
-                showTime
                 startDate={startDate ?? undefined}
                 endDate={endDate ?? undefined}
                 onRangeChange={handleDateRangeApply}

apps/sim/lib/billing/application/organization-usage/get-organization-usage-summary.ts

@@ -75,7 +75,8 @@ export const getOrganizationUsageSummary = defineAuthorizedOrganizationUsageUseC
       bucket,
       totals: { credits: dollarsToCredits(totals.cost) },
       previousTotals: previous ? { credits: dollarsToCredits(previous.cost) } : null,
-      series: densifyUsageSeries(seriesRows, window, bucket).map((point) => ({
+      // Same timezone the query grouped by, or the series keys cannot match its rows.
+      series: densifyUsageSeries(seriesRows, window, bucket, input.timezone).map((point) => ({
         timestamp: point.timestamp,
         credits: dollarsToCredits(point.cost),
         events: point.events,

apps/sim/lib/billing/core/usage-analytics.test.ts

@@ -114,6 +114,38 @@ describe('resolveUsageAnalyticsWindow', () => {
     })
   })
 
+  it('covers exactly the days the picker emitted, from its bare date bounds', () => {
+    // The picker sends `YYYY-MM-DD`, which parses as UTC midnight. It must not send
+    // an inclusive `…T23:59:59` wall time: the extra day added below would then land
+    // on the *following* day, and every custom range would overrun by 24 hours.
+    const window = resolveUsageAnalyticsWindow({
+      preset: 'custom',
+      period: period(),
+      customStart: new Date('2026-06-01'),
+      customEnd: new Date('2026-08-31'),
+      now,
+    })
+    expect(window).toEqual({
+      kind: 'range',
+      from: new Date('2026-06-01T00:00:00.000Z'),
+      to: new Date('2026-09-01T00:00:00.000Z'),
+    })
+  })
+
+  it('accepts a selection of exactly the maximum span', () => {
+    // June 1 through August 31 inclusive is 92 days. It measured 93 while the end
+    // bound carried a time of day, so the longest legal pick was rejected.
+    expect(() =>
+      resolveUsageAnalyticsWindow({
+        preset: 'custom',
+        period: period(),
+        customStart: new Date('2026-06-01'),
+        customEnd: new Date('2026-08-31'),
+        now,
+      })
+    ).not.toThrow()
+  })
+
   it('refuses a custom range beyond the cap rather than scanning the ledger', () => {
     expect(() =>
       resolveUsageAnalyticsWindow({
@@ -162,7 +194,8 @@ describe('densifyUsageSeries', () => {
     const points = densifyUsageSeries(
       [{ bucketStart: '2026-08-02T00:00:00', cost: '1.50', events: 3 }],
       window,
-      'day'
+      'day',
+      'UTC'
     )
     expect(points).toHaveLength(3)
     expect(points.map((p) => p.cost)).toEqual([0, 1.5, 0])
@@ -176,16 +209,74 @@ describe('densifyUsageSeries', () => {
         { bucketStart: '2026-08-03T00:00:00', cost: '2.75', events: 2 },
       ],
       window,
-      'day'
+      'day',
+      'UTC'
     )
     expect(points.reduce((sum, p) => sum + p.cost, 0)).toBeCloseTo(4, 8)
   })
 
   it('emits an empty series for a zero-length window instead of looping', () => {
     expect(
-      densifyUsageSeries([], { kind: 'range', from: window.from, to: window.from }, 'day')
+      densifyUsageSeries([], { kind: 'range', from: window.from, to: window.from }, 'day', 'UTC')
     ).toEqual([])
   })
+
+  it('keys days by the viewer calendar the query grouped by, not UTC', () => {
+    // Auckland is UTC+12, so the window's final instant is already the next local
+    // day. Walking UTC dates dropped that bucket: its cost stayed in the headline
+    // while its bar was never drawn.
+    const points = densifyUsageSeries(
+      [{ bucketStart: '2026-08-04T00:00:00', cost: '5.00', events: 1 }],
+      window,
+      'day',
+      'Pacific/Auckland'
+    )
+    const keys = points.map((p) => p.timestamp.slice(0, 10))
+    expect(keys).toEqual(['2026-08-01', '2026-08-02', '2026-08-03', '2026-08-04'])
+    expect(points.at(-1)?.cost).toBe(5)
+  })
+
+  it('aligns week buckets to Monday, as `date_trunc` does', () => {
+    // A period starting mid-week previously produced keys Postgres never emits, so
+    // every bar read zero while the total was correct. Reachable through an annual
+    // enterprise period, which resolves to `week`.
+    const points = densifyUsageSeries(
+      [{ bucketStart: '2026-08-10T00:00:00', cost: '9.00', events: 4 }],
+      // 2026-08-15 is a Saturday; its ISO week starts Monday 2026-08-10.
+      {
+        kind: 'range',
+        from: new Date('2026-08-15T00:00:00.000Z'),
+        to: new Date('2026-08-29T00:00:00.000Z'),
+      },
+      'week',
+      'UTC'
+    )
+    expect(points.map((p) => p.timestamp.slice(0, 10))).toEqual([
+      '2026-08-10',
+      '2026-08-17',
+      '2026-08-24',
+    ])
+    expect(points[0].cost).toBe(9)
+  })
+
+  it('aligns month buckets to the first, as `date_trunc` does', () => {
+    const points = densifyUsageSeries(
+      [{ bucketStart: '2026-09-01T00:00:00', cost: '3.00', events: 2 }],
+      {
+        kind: 'range',
+        from: new Date('2026-08-15T00:00:00.000Z'),
+        to: new Date('2026-10-15T00:00:00.000Z'),
+      },
+      'month',
+      'UTC'
+    )
+    expect(points.map((p) => p.timestamp.slice(0, 10))).toEqual([
+      '2026-08-01',
+      '2026-09-01',
+      '2026-10-01',
+    ])
+    expect(points[1].cost).toBe(3)
+  })
 })
 
 describe('foldUsageBreakdown', () => {

apps/sim/lib/billing/core/usage-analytics.ts

@@ -206,31 +206,83 @@ function toNumber(value: string | number | null | undefined): number {
   return Number.isFinite(parsed) ? parsed : 0
 }
 
+/** The `YYYY-MM-DD` an instant falls on in the viewer's calendar — what `AT TIME ZONE` produced. */
+function localCalendarDate(instant: Date, timezone: string): string {
+  return new Intl.DateTimeFormat('en-CA', {
+    timeZone: timezone,
+    year: 'numeric',
+    month: '2-digit',
+    day: '2-digit',
+  }).format(instant)
+}
+
+/**
+ * Civil-date arithmetic on a `YYYY-MM-DD` key.
+ *
+ * UTC is used purely as a proleptic calendar here — these values are never converted
+ * back to an instant, so no offset or DST transition can shift them. Doing the same
+ * arithmetic on a real local instant is what would break across a DST boundary.
+ */
+function civilDate(key: string): Date {
+  return new Date(`${key}T00:00:00.000Z`)
+}
+
+function civilKey(date: Date): string {
+  return date.toISOString().slice(0, 10)
+}
+
+/**
+ * Mirrors Postgres `date_trunc(bucket, …)`: an ISO week starts Monday, a month on
+ * the 1st. The series keys have to land on the same boundaries the SQL emitted or
+ * no lookup below will ever hit.
+ */
+function truncateToBucket(key: string, bucket: UsageBucket): string {
+  const date = civilDate(key)
+  if (bucket === 'week') date.setUTCDate(date.getUTCDate() - ((date.getUTCDay() + 6) % 7))
+  else if (bucket === 'month') date.setUTCDate(1)
+  return civilKey(date)
+}
+
 /**
  * Fills every bucket in the window, because SQL only returns buckets that have rows.
  *
  * A period with no usage must render a flat zero line, not the chart's "No data"
  * branch — zero is information, "No data" reads as a failure.
+ *
+ * The keys are generated in the *same calendar the query grouped by*:
+ * `readUsageTimeSeries` truncates `created_at AT TIME ZONE <timezone>`, so a viewer
+ * east or west of UTC buckets rows by their own calendar date. Walking UTC dates
+ * here instead dropped the edge buckets of every non-UTC window — their cost stayed
+ * in the headline while their bar read zero. Week and month were worse than an edge
+ * case: Postgres aligns those to Monday and the 1st, so a cursor stepping from an
+ * arbitrary period start shared no key with the query at all and the whole chart
+ * came back zeroed. That is reachable today through an annual enterprise period,
+ * which resolves to `week`.
  */
 export function densifyUsageSeries(
   rows: SparseBucketRow[],
   window: UsageAnalyticsWindow,
-  bucket: UsageBucket
+  bucket: UsageBucket,
+  timezone: string
 ): UsageSeriesPoint[] {
   const byBucket = new Map<string, SparseBucketRow>()
   for (const row of rows) {
     if (row.bucketStart) byBucket.set(row.bucketStart.slice(0, 10), row)
   }
 
   const { start, end } = usageWindowBounds(window)
+  const first = truncateToBucket(localCalendarDate(start, timezone), bucket)
+  // The window is half-open, so the last bucket is the one holding its final instant.
+  const last = truncateToBucket(localCalendarDate(new Date(end.getTime() - 1), timezone), bucket)
+
   const points: UsageSeriesPoint[] = []
-  const cursor = new Date(Date.UTC(start.getUTCFullYear(), start.getUTCMonth(), start.getUTCDate()))
-  const limit = end.getTime()
+  const cursor = civilDate(first)
   let guard = 0
 
-  while (cursor.getTime() < limit && guard < 1000) {
+  // `YYYY-MM-DD` sorts lexicographically in calendar order, so this compares dates.
+  while (civilKey(cursor) <= last && guard < 1000) {
     guard += 1
-    const key = cursor.toISOString().slice(0, 10)
+    const key = civilKey(cursor)
     const row = byBucket.get(key)
     points.push({
       timestamp: `${key}T00:00:00`,