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 a degree of their natal Ascendant this quarter, and you get a sorted list of matches with dates, orbs, phase and a significance score. No other astrology tool does this. The scanner is part of the $29 per month Adept plan; see pricing.
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 opens into. For the whole-life view of a single client, see life cycles.
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 which of them have the eclipse degree close to 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 spreadsheet exercise. You open each chart, eyeball the degree, write a name on a list. By the time you finish, half the windows have shifted.
The scanner runs the same question as one scan. Set the formula, pick who is in scope, and read the result. Save the filter and it re-runs next week. Turn it into an alert rule and it watches on its own.
What you can actually ask it
The filter bar is the query language, and it is small on purpose.
- Transiting bodies. Grouped as luminaries, personal, social, outer, points and asteroids. Multi-select.
- Aspects. Hard, soft, minor and angles. Multi-select.
- To natal. The natal points a contact has to hit. This is the axis that makes "Saturn square anything" into "Saturn square natal Mars".
- Orb profile. Per body, rather than one number for everything, with a separate near-miss ceiling that decides which unperfected close approaches are admitted. Every exact hit returns regardless.
- Window. This week, this month, the next 90 days, six months, a year, the same spans backwards, past six to next six, or a custom range.
- Phase and direction. Applying or separating, perfecting direct or retrograde.
- In force now. Narrows a forward scan to what is inside the orb profile today.
Scope stacks on top: the whole roster, a tag, a lifecycle status, or a handpicked list of clients.
Six techniques, one list
A scan does not only return aspects.
- Transits. A real ephemeris position, dated to the day, and repeatable over a retrograde loop.
- Solar arc. Perfects exactly once, with no return pass, and dated to the month rather than the day. The row says so, because solar arc advances about 0.95 degrees a year and a day-level date would be invented.
- Stations. The transiting body turns on the aspect degree, so it parks there for weeks instead of passing through. Flagged with its own badge, because a station is a different animal from a transit that crosses.
- House ingresses. A cusp crossing in the client's own chart. There is no orb at a crossing: the body is on the cusp.
- Eclipses. An eclipse on a natal degree, marked as a marker and not as an ordinary lunation.
- Lunations. A Sun–Moon syzygy, made this client's by the natal contact named beside it.
Each row carries its pass count, whether it is exact or a close approach, its phase, its direction, its orb and a severity. Scored rows are ranked by significance; rows the engine does not score are ranked separately by severity, then orb, then date, and an explainer panel shows exactly what produced the order.
Where a time-lord technique confirms the same period, the row says which system confirmed it.
Precision is stated, not implied
The scanner is careful in the place most tools are careless.
A client with no birth time on record has a chart cast for noon. Half a day either way moves the angles enough to shift a solar arc contact by a month or more, and the row states that slack instead of printing a confident date. Solar arc rows carry month precision as a label, not as a footnote. A solar arc contact cannot be added to a calendar at all, and the interface explains why: there is no day to put in one.
List or timeline
The same scan reads two ways. The list is the working surface for triage. The timeline is a Gantt view where a month with five overlapping contacts appears as five stacked bars, which is the fastest way to see that a client has a hard quarter coming, not a hard week.
Alert rules
A rule is a saved question plus a schedule.
Give it a name, such as Saturn hard aspects to luminaries. Choose transit planets, aspects and natal points. Set an orb, decide whether retrograde passes count, and pick a rarity. Point it at the whole roster, a set of tags, a set of lifecycle statuses, or specific clients. Then choose when it reaches you: on entering the orb, on exact, in a daily digest or a weekly one, with a check frequency of daily, weekly or monthly and a look-ahead measured in days. The $79 Master plan raises the look-ahead ceiling to 90 days.
Five starter rules are offered for the obvious cases: the Saturn return, hard outer-planet aspects to the luminaries and angles, Jupiter returns and openings, nodal-axis hits, and Pluto transits. The nodal-axis preset is named accurately: it finds transiting nodes on natal points, which is where eclipses land, and it is not an eclipse detector.
The interface keeps rules and saved filters apart, and labels a saved filter as re-running the filter bar rather than alerting. Conflating the two is how people end up believing they are being watched when they are not.
Three weeks of practitioner workflow
Monday morning
The weekly digest is in your inbox. Three clients are inside a Saturn contact to an angle, two have an eclipse on a natal light, several more are in inner-planet stations. The first twenty minutes of your week is not chart-pulling. It is deciding who to email, in what order.
Wednesday, mid-day
A long-running client emails: something feels off, can we talk. Instead of opening her chart cold, you scan her alone over a short window and get every contact inside her orb profile with dates, phase and time-lord confirmation. The question of what is happening structurally is answered before the call starts.
Friday, end of week
You save the filter you have been refining all week and turn the useful half of it into an alert rule with a 30-day look-ahead. Next month it finds the match before you think to look for it.
Versus what you have now
Solar Fire: No roster search. Each client is a file. The closest equivalent 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, with no concept of a practitioner roster.
By hand: Around 90 minutes per question across 200 clients with a spreadsheet, and the answer is stale within a week.
Astrolium: One scan across the cohort you choose, six techniques in one list, precision stated per row, saved filters, alert rules, CSV export, and every result opening straight into the client's predictive timing.
Where it sits in the stack
The scanner is built on the same ephemeris foundation as the predictive timing ribbon and the Saturn return calculator. What is different is the shape of the question: not one chart over time, but every chart at once.
Astrolium used to ship two neighbouring modules, Transit Search and Time Report. Both read the same event stream, the scanner's filter set was a strict superset of either, and its rows carried real activation windows, pass counts, stationary flags and a significance score that neither predecessor computed. Keeping three doors onto one room helped nobody, so the other two were retired into this one.
Cross-link
For the single-client timing surface a result row opens into, see predictive timing. For the whole-life developmental view, see life cycles. For couples work that appears in scanner results too, see synastry. For the migration path from a Solar Fire export, see Solar Fire vs Astrolium. 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.