Subscription Duration and Status
The two dates that matter
Every subscription has a current paid period defined by two values:
| Field | Meaning |
|---|---|
CurrentPeriodStart |
The moment the paid period begins |
CurrentPeriodEnd |
The moment the paid period ends |
The length of the period comes from the term you purchased. Terms are counted in whole months, so a one-month term adds one month to the period and a twelve-month term adds twelve. A trial uses its own end date instead.
Authorized users can see the current status and both dates on the subscription page in the dashboard.
Subscription statuses
| Status | Grants operational access? |
|---|---|
| Trial | Yes, until the trial end date. A trial with no end date is open-ended. |
| Active | Yes, while the current period has started and has not yet ended. |
| Suspended | No |
| Expired | No |
| Cancelled | No |
Your organization's own status matters too. If the organization itself is suspended by the platform team, operational access stops regardless of subscription dates — that is a separate situation from expiry, and it is resolved by the platform team rather than by renewal.
When access actually stops
Access is decided by time, not by a stored label.
The moment
CurrentPeriodEndis reached, subscription-required operations are refused.
A subscription whose period has not started yet is also refused — a future CurrentPeriodStart does not grant access early.
Stored status can lag behind, and it does not matter
A background process updates the stored Status column to Expired and sends the related notifications. It runs when the application starts and once every hour after that.
That means there is a window — up to an hour — in which the database still shows Active while the period has in fact ended. During that window, operations are already refused.
This is deliberate. The stored status is a record of a decision that has already taken effect; it is not the thing that makes the decision.
There is no grace period
None of the following extends access past CurrentPeriodEnd:
- The stored
Statuscolumn still readingActive. - The hourly background process not having run yet.
- A browser session started while the subscription was still active.
- A mobile app token issued while the subscription was still active.
- A public survey link or viewer link created earlier.
- Any internal caching.
There is no hidden window of extra usage, intentional or accidental.
Technical note. The access check reads your organization's current subscription from the database on every protected request. It keeps no cache of its own. A separate short-lived cache holds plan limit values, but that cache never decides whether the subscription is in force.
Before the period ends
Survanta produces pre-expiry reminder events at 30, 14, 7, 3, and 1 day remaining. A reminder is produced only when the whole number of calendar days left matches one of those values exactly — a subscription eighteen days out produces no reminder rather than an early one.
| Signal | What is guaranteed |
|---|---|
| Subscription page | Shows the current status and both period dates to authorized users |
| Reminder events | Produced at the stages listed above, once each, without duplicates |
| Refusal messages | Name the specific reason and the relevant date when an action is blocked |
| Public links | Return only a neutral "unavailable" response, never your billing state |
| Email delivery | Depends on your deployment's mail configuration; ask your platform team to confirm it is active |
Setting your own calendar reminder before the displayed end date remains good practice.