Astrolium's transit scanner reads the whole roster the way a search engine reads the web. You ask a structural question ("which of my clients has transiting Saturn within 1 degree of their natal Ascendant right now") and 90 ms later you have a sorted list of matches with orb tightness, current ZR period, and tag. Zero competitor tools do this. The CRM-plus-transit-engine combination is the moat: one Friday afternoon client outreach campaign earns the $29 per month subscription back inside week 1.
The Saturn return guide shows the kind of structural pattern the scanner surfaces across a roster. The predictive timing feature is the engine each row in the result list opens into. For the $29 per month Pro plan that includes the scanner and 5,000 client slots, see pricing.
What the scanner replaces
The problem is shaped like this. You have 200 paying clients on your books. Eclipse season is coming. You want to know, quickly, which of them have the eclipse degree within 1 degree of a natal Sun, Moon, or angle, because those are the ones who need a check-in next week. In every other piece of astrology software, this is a 90-minute spreadsheet exercise. You open each chart, eyeball the eclipse degree, write a name on a list. By the time you finish, half the windows have shifted.
The scanner runs the same query in 90 ms. Type the condition, watch the count tick up as it scans, click any name to open that client's chart with the conjunction pre-highlighted. Pin the query and Astrolium keeps watching for the next eclipse, the next station, the next ingress.
What you can actually ask it
The query language is small on purpose. Most working questions fit one of four shapes:
- Planet on point. Saturn within 1° of ASC. Pluto within 2° of Sun. Transiting Jupiter conjunct natal Mars. Any orb you set, any pair you choose.
- Aspect window. Any outer planet within 1° of any personal planet, applying only. Returns the clients in active malefic windows without you having to remember whose Mars sits where.
- House activity. Transiting planet in the client's 7th house, this month. Works in whole-sign or Placidus per client. Useful before couples-counselling weeks.
- Timing-layer crosscut. Clients on a peak ZR sub-period AND with Saturn squaring their Sun within 30 days. The composite of two filters that no other tool stacks.
You can also stack non-astrological filters on top. Tag a subset of your roster "premarital prep" and the scanner respects the tag: same query, only those clients. Filter by birth year, by school (Hellenistic, evolutionary, modern, Vedic), by last session date, by location. Stacked filters land in the same 90 ms budget for rosters up to 5,000 clients.
Three weeks of practitioner workflow
The scanner is one of those features that changes the shape of the work week without you noticing. A few patterns we see repeatedly from beta practitioners:
Monday morning, 7:00 am
The Sunday digest is in your inbox: 11 clients with new transits inside their critical orbs as of Monday. Three are Saturn-on-ASC. Two are eclipse on a natal angle. Six are inner-planet stations on a personal planet. The first 20 minutes of your week is not chart-pulling. It is deciding who to email, in what order. The scanner did the triage at 3 am.
Wednesday, mid-day
A long-running client emails: "something feels off, can we talk?" Instead of opening her chart cold, you run the scanner on her ID alone, get a one-screen panel of every transit, profected lord, and ZR shift inside her active orbs. The answer to "what is happening structurally" is loaded before the call starts. Session prep dropped from 25 minutes to 4.
Friday, end of week
You pin a query for the next 30 days: "any client with transiting Mars within 1° of natal Mars." Saturday morning the scanner pings: a new match. You see it before the client notices the day feeling sharp. The follow-up email goes out before the weekend.
Versus what you have now
Solar Fire: No roster search. Each client is a file. The closest thing is a transit report per chart, one at a time.
Astro Gold: No roster search. The client list is a contact list, not a queryable database.
TimePassages: Consumer-grade transits per user, no concept of a practitioner roster.
By hand: ~90 minutes per query across 200 clients with a spreadsheet. The answer is stale within a week.
Astrolium: Sub-second roster-wide queries, stacked filters, saved alerts, the result list opens straight into each client's predictive timing ribbon.
A few queries to start with
If you have not used a scanner before, these are the ones beta users save first:
- Saturn on ASC within 1°. Returns clients in the structural identity-and-body window. Common before a Saturn-return cohort check-in.
- Any outer planet within 1° of Sun or Moon. Catches the heaviest transits across the roster, irrespective of which outer.
- Eclipse season hits within 30 days, orb 1°. A two-week prep list during March and September.
- Clients on a loosing-of-the-bond inside 60 days. Hellenistic timing crosscut, surfaces the chapters about to end.
- Mars station within 5° of any angle, next 90 days. The pre-irritability list, useful for couples work.
Save the query once and the scanner watches the next 12 months for new matches.
Where it sits in the stack
The scanner is built on the same Swiss Ephemeris foundation as the predictive timing ribbon and the Saturn return calculator. Positions match to the arc-second across the 1900–2100 range. The thing that is new is the index. Every client's natal points are pre-hashed into a search-ready structure, so the cross-roster join happens in memory instead of from disk.
For the broader feature set the scanner composes with, see the synastry feature (couples appear in scanner results too; composite Sun within orb of an eclipse triggers the bowtie), predictive timing, and the Solar Fire vs Astrolium comparison for the migration path from a Solar Fire export. For a worked walkthrough of saving a roster query, alerting on new matches, and turning the result into a client outreach campaign, see the transit-scanner workflow tutorial.
A working roster is a database. Astrolium treats it that way. The scanner is the consequence.