## TL;DR
Your phases have overlapping start and end dates. Fix the boundary so each phase starts exactly when the previous one ends, or leave end dates off and let phases chain. Then resubmit the schedule.

```text
phase overlaps
```

## Use this when
- Creating or updating a subscription schedule returns a phase-overlap error.
- You are chaining trial, intro pricing, and standard pricing phases.
- A schedule edit moved a phase start and broke the chain.

## Not for this skill when
- The error is about phase start dates in the past. That is a date-validity problem.
- You are updating a plain subscription, not a schedule. Schedules have their own API.

## Steps
1. ('List the phases with their start_date and end_date values. Verify: you can see the exact overlap.', 'Set each phase end_date to equal the next phase start_date, or drop end_date and let chaining handle it. Verify: no two phases share a timestamp.', 'Resubmit the schedule create or update. Verify: the API accepts it and returns the schedule id.', 'Release or preview the schedule to confirm the customer sees the right prices per phase. Verify: the phase preview matches the intended timeline.', 'If the overlap came from an automated phase builder, fix the boundary math there. Verify: generated schedules chain cleanly.')

## Variant phrasings
### stripe subscription schedule phases overlap
Reordered phrasing.

### phase overlaps subscription schedule api
API-context search.

### stripe schedule phase boundary error
Boundary phrasing.


Compatibility: Stripe Billing subscription schedules API, all client versions.

## Why it happens
Subscription schedules are time-chained: at any moment exactly one phase must be active. An overlap means Stripe cannot tell which price applies at the boundary timestamp, so it rejects the schedule rather than guessing. The usual cause is setting end_date to the same day a human reads as "the last day" while the next phase starts at midnight of that same day.

## Edge cases / pitfalls
- Phases use Unix timestamps, not dates. Off-by-one-day mistakes are timestamp mistakes.
- A schedule with one phase cannot overlap; if you see this with one phase, the stale phase data is cached client-side.
- Releasing a schedule locks it. Preview before release.
- Automation that adds phases must be idempotent; double-run builders create the overlap.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_59U6WfYP-XM0gjcotwODrQ