Capitan Release Notes - September 14, 2026

What's in this release

The Chart Builder's numbers can now be read directly under a chart or on a dashboard, the front desk gets an alert when someone checks in without a proficiency their location requires, and guest passes can be offered to customers who have not visited in a while. Also in this release: clearer membership statuses, new report columns, and a number of smaller changes.

Chart Builder and dashboards

Customers and check-ins

Memberships and billing

Reports and exports

Events and bookings

Integrations

Plus a number of fixes, at the end of this article.

Chart Builder and dashboards

Chart Builder: new Data and Comparison tabs

Previously, the Chart Builder was the only chart report in Capitan that did not show its numbers on screen. Every built-in chart report lists its data in a table beneath the chart; a custom chart's figures could only be reached by downloading the CSV or XLSX export, which made a question like "what was the figure on the 14th?" harder than it should be.

A chart in the Chart Builder now has Data and Comparison tabs beneath it. Data lists the chart's numbers as a table with a total row. For each comparison period, Comparison shows two figures side by side: the figure for the portion of the period that has elapsed so far, and the Full period figure.

The Comparison tab shows figures the percent change badge could not. The percent change already compared only the elapsed part of the current period, but the underlying numbers were never shown. If you wanted to compare a month in progress against the same month last year, you had to work the elapsed figures out by hand. Both figures are now shown.

The Comparison tab only has something to show on a chart that has a Compare to period set.

Dashboards: new Data Table and Comparison Table tiles

A dashboard can now carry a Data Table tile and a Comparison Table tile alongside the existing Chart tile, so the numbers behind a chart sit on the page staff keep open rather than a click away in the Chart Builder. Each is built from a chart exactly the way a chart tile is. A Data Table tile offers Rows per Page so a long series does not take over the dashboard; a comparison table is one group per metric and needs no paging.

A Comparison Table tile needs a chart that compares to an earlier period. Choosing one that does not shows a warning in the tile setup rather than an empty tile, pointing you back to set a Compare to period in the Chart Builder.

Chart Builder: new metric type for membership status changes

Previously, freezes were reportable through the Membership Freeze Logs report, but an unfreeze existed only as a status change on an individual membership, visible on one account and nowhere else. The same was true of every other membership event a manager might want to track over time.

A new Membership Status Changes metric type counts membership status-change events over time, and can be charted and compared period over period like any other metric. For each metric you choose which event to count, from Frozen, Unfrozen, Ended, Payment Failed, Payment Recovered, and Ended after Payment Failure, and the metric can be filtered by billing location and by membership.

Historical counts are included, so a chart of these events looks back rather than starting from today.

Every metric type, including Membership Status Changes, is covered in Chart Builder: Metric Types Explained.

Dashboards: start the Locations filter on each viewer's own location

A multi-location organization can now build one manager dashboard that shows each manager their own location's numbers. Saving a dashboard offers Start the Locations override filter on each viewer's own location. With it on, anyone opening that dashboard sees their own default location first and can still switch to another, the same way the events calendar has always opened on the staff user's own default location.

Without the option, a dashboard behaves as before: each tile uses the locations it was built with, and the Locations override filter starts empty. The option appears wherever you save a dashboard, and is hidden for single-location organizations, where it does not apply.

Customers and check-ins

New guest pass mode: Lapsed Customers Only

Previously, a guest pass was either All Customers or New Customers Only, where "new" means never checked in. There was nothing in between for winning back a customer who has been before but has gone quiet.

Guest passes now have a third mode, Lapsed Customers Only, for customers whose last check-in at any of your locations was more than a set number of months ago, and for customers who have never checked in at all. The number of months is one setting for the whole organization, on the Organization Settings page under "For 'lapsed customers only' guest passes, how many months without a check-in make a customer eligible?". It defaults to 12.

Changing that setting applies immediately to every outstanding lapsed-customer pass. Passes do not carry their own copy of the setting, so nothing needs reissuing after a change. Existing passes and membership configurations behave exactly as they did before this release.

The new mode is available wherever the other two already are. Membership types gain a third guest pass benefit, for the number of Lapsed Customers Only passes and their frequency, and the same fields appear on memberships attached to rolling events. Existing members receive the new passes on the same schedule as a change to the other two benefits does today. Manual guest pass creation, single and bulk, now offers all three modes in one dropdown, replacing the old Yes or No "New Customers Only?" question.

The "Use Guest Pass" picker now explains why a pass cannot be used. Passes the customer is not eligible for are shown but disabled, with the reason, such as "Not eligible: customer last checked in on 3 Mar 2026" or "Not eligible: customer has checked in before". This is a change for New Customers Only passes too, which were previously hidden from the picker altogether. Eligible passes are listed first.

The Guest Passes (All Customers) profile field and the kiosk count are unchanged. Both continue to count only All Customers passes; the Guest Passes count includes all three modes.

Redeeming a pass at the desk is covered in Check-in with a Guest Pass.

Check-In Site: alert when a customer lacks a required proficiency

Some locations offer different activities from the rest of your organization. A customer with only a bouldering proficiency checking in at a roped location is someone staff should have a word with. Previously, nothing prompted that: staff had to notice which proficiency badges were missing, which is easy to miss during a check-in rush.

Each location can now name the proficiencies required to check in there. On the Location Settings page, Required proficiencies for check-in is a checkbox list of your organization's proficiencies, and Alert unless the customer holds chooses between Any one of the selected proficiencies, the default, and All of the selected proficiencies.

When a customer checks in at the Check-In Site kiosk at that location without satisfying the requirement, the check-in still completes normally, a new Check-In Success with Missing Proficiency sound plays, and a warning banner names what they are missing: "Proficiency Check: [Customer] is missing the [Proficiency] proficiency required at [Location]." The banner shows in both of the kiosk's display modes.

The alert never blocks or delays the check-in. There is no confirmation step and no extra click.

A proficiency counts as held only when it is active: not removed, not expired, and with its granting document, where there is one, approved and valid. This is the same rule that decides which proficiency badges appear on the staff Check-In page.

You need to choose the new sound for it to play. It is configured on the Check-In Sounds page alongside the existing sounds, and it takes priority over the other success sounds. Until one is chosen, the check-in plays whatever sound it would have played anyway, and the banner still shows. Leaving every proficiency unchecked on a location turns the alert off there.

What each check-in sound means is covered in What do I do when I hear the alert noise at check-in?.

Staff Site: the same proficiency warning on staff check-ins

The alert above covers the Check-In Site kiosk. Staff checking a customer in from the Staff Site saw only a green success message, so the same situation went unnoticed.

After a check-in from the customer profile's Check-Ins card, whether through Manual Check-In, Use Shared Pass or Use Guest Pass, a yellow warning now appears beside the green success message naming the missing proficiencies with their icons, worded identically to the kiosk banner. The Staff Site Check-In page gets the same warning.

The warning is informational only, exactly as on the kiosk: no confirmation, no extra click, no sound. It clears when the next check-in attempt starts, along with the existing success and error messages.

Customers report: new Add To Association bulk action

Previously, putting a set of customers into an Association meant uploading a CSV or adding them one at a time, even when the customers were already in front of you as the result of a report.

The Customers report's Bulk Actions menu now includes Add To Association, sitting alongside the existing options, where you pick the Association the selected customers are added to.

What an Association is and what it can do is covered in Associations Overview.

Memberships and billing

Customer profile: Membership Status covers more states

Previously, the Membership Status field on the Staff Site customer profile, the Check-In Site and the Check-Out Site only distinguished an active membership from everything else. A frozen member, a member whose renewal payment had failed, a membership awaiting staff review and a membership that had not started yet all read None, which is confusing for a customer who plainly still has a membership.

The field now reports the first of these that applies: Member until [date] or plain Member, Pending Staff Review, Frozen until [date] or Frozen, Payment Failed, Payment Pending, Awaiting Payment Method, Starts [date], and None.

A date is shown only when something is scheduled to end or pause the membership: a prepaid membership's expiry, a cancellation or freeze booked on a recurring one, or this customer's own freeze or pending removal from a group membership. A recurring membership's next bill date is not shown, since a renewal is not a lapse.

Only this customer's own place in a group membership counts. Another member freezing or being removed gives this customer no date, since they carry on using the membership.

A customer holding several memberships shows the status highest in the list above, so an active membership still wins over a frozen one. The Customer Profile Config preview is unchanged.

Activity log: payment method changes

Previously, adding a saved card, removing one, and changing the payment method on a membership left no activity log entry for the action itself. Only the automatic downstream effects were recorded, such as a "membership restored" line, so there was no way to tell whether a staff user or the customer had made the change.

Each of those three actions now writes its own entry, attributed the way every other membership and billing action already is: "[Staff Name], Staff, on behalf of [Customer]" when done through the Staff Site, or the customer's own name when they did it themselves. Existing Automatic entries still appear, now alongside the entry naming the action that triggered them and who took it.

New membership status: Awaiting Payment Method

Previously, a recurring membership went active as soon as its first invoice was fully paid, whether or not anything had been saved that could collect the next payment. This could happen three ways: account credit that covered the first payment, a point-of-sale gift card, and a discount that brought only the first period to zero. The membership went live, the customer got full access, and the problem surfaced weeks later as a renewal failing with "No payment method", by which point the money was already owed.

A recurring membership whose first payment completes with no saved payment method now stops at Awaiting Payment Method instead of activating. The membership does not grant access until it is activated, and saving a payment method activates it immediately, wherever a payment method can be saved: the Climber App billing page, the purchase page itself, or a staff user adding one from the Staff Site.

A customer can always find a membership they have paid for. Immediately after paying they see a confirmation page saying the membership is not active yet and that saving a payment method activates it. That message stays if the page is refreshed. The membership stays visible in the Climber App with a Finish Setup action rather than Manage. Fifteen minutes after the membership enters Awaiting Payment Method, its owner is emailed a link to finish setting it up, and the link works without signing in. Adding a payment method inside those fifteen minutes means no email is sent.

A membership that costs nothing now and whose next bill is also expected to be nothing still activates immediately, since nothing will ever be charged. A free membership, or one held at zero indefinitely by a staff discount, is unaffected.

Staff can still activate a membership without a payment method. In a staff-assisted sale, a separate action does exactly that, for a member at the desk who has no card with them, and it is available however the first payment was made. Staff can also cancel a membership that is awaiting a payment method from the customer profile's Memberships and Passes list, choosing whether the money goes back to where it came from or is issued as account credit instead. If the original payment cannot be refunded through Capitan (offline, Lightspeed or Square), the cancellation is refused up front, so a membership is never cancelled with the money left in limbo.

Nothing cancels these memberships automatically. They wait indefinitely until activated or cancelled by staff. You can find them on the Memberships report by filtering the status to Awaiting Payment Method.

One related change to the staff-assisted payment page: applying account credit that would cover the whole remaining balance now asks for confirmation first, naming the amount and saying that it completes the purchase. Partial credit is still applied without asking, because it can be undone.

Memberships that are already active without a payment method are unaffected, and keep behaving as they do today. Prepaid memberships are unchanged.

Reports and exports

Payments report: new Time column and Timestamp export column

Previously, the Payments report showed the date of each payment but not the time of day, and neither the table nor the export offered a way to see it. Reconciling a processor payout, investigating a disputed charge, or matching a payment to a check-in meant opening each payment individually or falling back to the payment processor's own dashboard.

The report now offers a Time column on screen and a raw Timestamp column in the export. This is the same layout Check-In History already uses, with Check-In Time and Check-Out Time columns on screen and raw timestamp columns in its export.

Event attendee export: new money columns

Previously, the Export Event Attendees modal offered a Fee type column, but it contained only the fee's name, such as "First Climber", with no amount. Money was available at the booking level through the Bookings report and nowhere at the participant level, which made comparing an event's revenue against the cost of the shift that worked it awkward.

The export now offers Invoiced amount, Amount paid and Amount refunded columns per attendee.

These per-attendee amounts are calculated, not recorded. Fees are recorded against the booking's invoice, and one booking can cover several participants, so a booking's money is divided among its participants to produce a per-attendee amount. The figures are exact at the booking level and divided among the participants below it.

Events and bookings

Schedule exceptions: choose between cancelling and replacing

A schedule exception does two things at once: it clears the usual sessions from the days it lists, and it creates a session at each time entered under Reservation Time Slots. Previously, the form never said so, and that one field silently decided between the two outcomes. Staff setting up a holiday closure reasonably read the time slots box as asking when the cancelled session would have run, entered the usual time, and got a closure that cleared the day and then scheduled an identical session back onto it.

The schedule exception form now asks What should happen on these days? with an explicit choice between Cancel the usual events and Run different events instead. The time slots only appear where they mean something.

The form is clearer, but the underlying behavior is unchanged. An exception with no time slots has always been a pure closure, and an exception with time slots has always been a replacement. The form now states which one you are configuring.

On an "All Rosters" exception, "Run different events instead" is not available, because such an exception can only remove sessions. That was already true and was already explained in the form; it is now reflected in the choice itself.

Schedule exceptions live on the event type, reached by opening it from Event Setup.

Waitlist entries: new Resend Invitation action

Previously, the per-entry Manage menu on a waitlist offered Re-invite To Book only for entries that had expired or been rejected. A pending entry, which is exactly the case where a family has been invited and has not answered, had no resend action at all. The only route was to reopen the Invite Waitlist Entry To Book window and search for each participant by name again.

A pending waitlist entry's Manage menu now offers Resend Invitation, which re-sends the invitation to that entry.

Resend Invitation also stops start dates and booking deadlines being wiped. Re-inviting through the invite window overwrites the entry's start date and booking deadline with the values in that window, and both fields are blank by default, so resending a batch of invitations that way cleared a batch of start dates and booking deadlines with no warning. Resend Invitation leaves them alone.

Integrations

Organization Settings: a failing integration now says so

Previously, an integration whose connection had stopped working failed silently. A Mailchimp connection that began returning an authorization error kept being retried every few minutes, no new customers reached the audience, and nothing anywhere in Capitan indicated that syncing had stopped. The same was true of Square and Lightspeed token failures.

A failed connection is now shown on the Organization Settings page beside the integration, reading This integration needs attention. followed by what happened and what to do, for example that syncing has stopped and the integration needs reconnecting to resume.

Syncing stays paused while the error stands, rather than retrying continuously. It clears when the integration is reconnected, or when the next sync succeeds.

If you have one of these warnings waiting for you after this release, the connection has been failing for some time and customers created in the meantime will not have reached that integration. Reconnecting is what resumes the sync.

Richer analytics data from the Climber App

Previously, the Climber App's analytics events sent only basic details: a product view carried the item's ID and name, and a purchase did not carry the product identifiers Meta uses to match ads to your catalog.

Both Meta and Google Analytics now receive the same richer details on those events, which improves catalog matching and campaign optimization for organizations running ads. Nothing needs to be turned on, and this is separate from the customer-matching settings introduced in the previous release, which remain opt-in.

One long-standing bug is fixed in the same change: a product whose name contained an apostrophe broke the tracking script on the page it appeared on, so no events were recorded from that page at all.

The two integrations are covered in Meta Pixel for the Climber App and Google Analytics for the Climber App.

Fixes

  • An abandoned, unpaid booking briefly blocked re-inviting or waitlisting the same participant. An unpaid booking no longer counts.
  • Duplicate-registration messages read as "already registered" whatever the payment state. They now distinguish a paid registration from one still awaiting payment, for staff and customers alike.
  • Booking a time slot from a waitlist invitation in the Climber App gave no sign it was working. The Schedule Time button now shows a loading state and cannot be pressed twice.
  • Members on iPhones could not sign in to the Climber App. A recent change did not work on some iOS versions. Sign-in works again on all of them.
  • Members were told "That page had been open too long" on a page they had just opened. This happened when the browser brought back a page from its cache, for example after pressing Back. Forms now work however the page was reopened.
  • Returning to an abandoned purchase showed a blank error page. It now says the purchase timed out, and the window before an unfinished purchase is cancelled has gone from one hour to one day.
  • An ended membership could still be edited, and reported days remaining and future bill dates. Those edits are now refused and the dates no longer shown. Nothing was ever billed.
  • The Customer Check-In Counts in Date Range report could time out when a minimum check-in count was set. This affected some organizations and not others. The report now completes.
  • A report that ran too long reported itself as "Could Not Reach Capitan". A timeout now says so plainly, and is distinguished from a genuine connection failure.
  • A bulk Association upload rejected valid-looking dates with no useful explanation. Dates written with slashes are now accepted, and a rejected upload shows the specific reason.

Still need help? Contact Us Contact Us