Read Credit Health without mistaking it for a credit score

Credit Health is not a credit report, a score, or a score simulator. GlidePath does not contact a bureau, fetch a report, run an inquiry, or calculate what a lender will see. It organizes the cards, loans, dates, and scores you chose to save around the five broad FICO factor categories.

That boundary matters. The Consumer Financial Protection Bureau explains that reports and scores are different things, that people have multiple scores, and that the result can vary by bureau data, model, loan type, and date. Use this page as a local checklist and trend view—not as a substitute for checking the underlying report.

What you’ll learn

• Which saved fields drive each part of Credit Health
• How to read overall and per-card utilization without turning a guide rail into a score promise
• What the score log does—and what it cannot prove
• Why the payment-history panel is a setup check, not payment verification
• Which history and inquiry facts GlidePath cannot see from the data you entered

Before you start

Add each revolving card on Credit Cards under Accounts. The minimum useful fields are Card name, Current balance, and Credit limit. Add Payment due date and Autopay if you want the payment-setup panel to say anything useful.

Installment credit comes from loans created on Accounts → + Add loan. The Origination date is what lets Credit Health include that loan in age and new-account counts.

One honest rough edge: the friendly + Add a card form does not currently offer an opened-date field. Credit Health can read the optional Opened column in credit-card-tracker.csv, but adding that card-history date still means editing the local file. If neither a card nor a loan has an open date, the page gives general history guidance instead of inventing an age.

Step 1 — Start with the boundary, not the number

Open Credit Health from Accounts in the top navigation. The banner says what the page can and cannot know: it cannot see your actual FICO or VantageScore, and it never pulls your credit file.

The five percentages on the page—payment history 35%, amounts owed 30%, length of history 15%, new credit 10%, and credit mix 10%—are the general-population FICO categories published by myFICO. FICO also says their importance varies by person and that the exact effect of one factor cannot be isolated without the full report. Read the weights as the page’s organizing frame, not a formula GlidePath can run on your local rows.

Try it: Open /CreditHealth ↗ (works when the desktop app is running on this computer—just browsing? See the demo)

Step 2 — Trace overall utilization to the cards

The statement begins with Overall utilization:

saved card balances ÷ saved credit limits

The provenance badge beside it names that source. Below, the per-card bars show the same relationship one card at a time, sorted from highest utilization to lowest. A paid-ahead card with a negative balance is clamped to 0% on this page rather than rendering a negative utilization.

GlidePath uses under 30% and under 10% as visible guide rails. The pay down figures are simply the dollar differences needed to move the saved total balance to those ratios against the saved total limit. They are not predictions of how many points a score will move, and they do not know when an issuer will report a new statement balance.

If an amount or limit is stale, update the source card before trusting the ratio. The page can be exact about the arithmetic and still be wrong about today when an input is old.

Step 3 — Read the utilization trend’s real window

The month-over-month chart is built from the Card total in net_worth_history.csv, divided by today’s saved total credit limit. It renders up to the latest 12 months.

That gives you a consistent current-limit comparison, with one important caveat: if your total limit changed, the older percentages are recalculated against the new limit. The chart is not a historical archive of what each issuer reported or what your utilization ratio was under the limits that existed at the time.

The chart can mark the first downward crossing from 30% or more to under 30%. It does not mark a month that began under the line, and it does not turn a later rise into an achievement.

Step 4 — Treat payment history as a setup check

Credit Health can count which saved card rows say autopay and list their saved due dates. Those dates also appear on Calendar.

It cannot see whether a payment cleared, whether the issuer reported it late, or whether a due date rolled to the next month. If the card row says manual, the page flags it as manual. If the saved due date is in the past, the page does not manufacture the next one. Keep those fields current at the source.

This is why the panel is best read as “is my setup designed to avoid a miss?” rather than “my payment history is clean.” Only your credit reports can answer the second question.

Step 5 — Understand the age, new-credit, and mix proxies

The lower panels use only tracked credit accounts:

• Length of credit history uses card Opened dates and loan origination dates to show the oldest and average age
• New credit counts tracked cards and loans whose saved open date falls in the last 12 months
• Credit mix lists revolving cards plus the distinct loan types in loans.csv

GlidePath does not track hard inquiries, closed tradelines that are absent from your files, collections, or the complete set of accounts on a bureau report. A “no new credit accounts” line means no recently opened tracked card or loan has a date—not “no inquiry exists.” And the mix panel explicitly does not justify opening an account just to add a type.

Step 6 — Log a score without claiming causation

GlidePath never fetches a score. In Your credit score, enter one you obtained elsewhere:

• Date (defaults to today)
• Score (300–850)
• Model (FICO Score 8, VantageScore 3.0, or Other)
• Source

The app saves it to credit-scores.csv, sorts entries by date, and shows the change from your first logged score to your latest. It places that beside the utilization trend so you can observe both.

Do not read the pairing as proof that one caused the other. The score window runs from the first log to the latest, while the utilization chart is a trailing current-limit view, and a real score can change because of report data GlidePath never sees. The CFPB’s current guidance is a useful reality check: a score depends on the report data, scoring model, source, and even the day it was calculated.

If you want the underlying reports, use the official route the CFPB names: AnnualCreditReport.com. A report and a score are different artifacts; correct report errors at the source rather than trying to explain them away in a local trend.

What just happened

You separated three kinds of evidence:

1. Current local inputs — card balances, limits, due dates, autopay text, and account dates
2. Local history — month-end card totals and scores you logged yourself
3. Bureau facts GlidePath does not have — the full report, inquiries, payment reporting, model-specific score inputs, and the score a lender may use

That separation makes Credit Health useful. You can fix a stale input, follow a suspicious number back to its saved row, and know when the honest next step is outside the app.

Common pitfalls

• Calling the page your credit score. It displays only a score you logged; it never generates one.
• Treating 30% as a guaranteed score threshold. It is a guide rail on the page, not a points forecast.
• Comparing the score delta and utilization trend as matching experiments. Their windows and source data differ.
• Reading autopay as proof of payment. The page knows the saved setup, not whether a payment cleared.
• Assuming “no new credit” means no inquiries. GlidePath counts dated tracked accounts; it has no inquiry feed.
• Forgetting the source rows. Update Cards, loan origination dates, and the optional card Opened field before drawing conclusions from the panels.