Why a Planned Trip Doesn't Show Its Airports Yet

You land, connect to the airport Wi-Fi, and open MapMyWorld to check your record. The flight you were just on isn't there. The country you just walked into hasn't changed colour on the map. Nothing is broken — the trip just hasn't started yet, as far as the app is concerned, and the reason is more deliberate than it looks.

Three statuses, not one

Every trip in MapMyWorld carries a status: planned, ongoing, completed, or cancelled. It sounds like bookkeeping, but that status is the actual gate on whether your airports and country get recorded at all. A trip you set up in advance — dates, flights, a destination — sits as planned right up until it starts. Nothing about having a planned trip adds anything to your record. It's a plan, not a visit.

That's a deliberate design choice, not an oversight. MapMyWorld doesn't monitor your phone's location and infer when you've arrived somewhere. You tell it. And "you tell it" has to mean something more precise than "you created an entry" — otherwise booking a flight six months out would already colour in the destination country, which would make the map a wish list, not a record.

What actually flips the switch

Two things move a trip from planned to ongoing, and either one records your airports and country the moment it fires.

The first is editing the trip yourself — changing its status, or letting an edit to its dates put today inside the trip window. The moment a trip's effective status becomes ongoing or completed, the app records the country as visited and adds any origin, destination, or layover airport tied to that trip (server/routes/trips.ts). A trip created with the status already set to completed — the common case if you're logging a trip after the fact — records everything immediately, on creation.

The second is a background job that runs once a day (and once at server startup) and advances trips automatically by date: planned becomes ongoing once the start date arrives and the end date, if there is one, hasn't passed yet; planned or ongoing becomes completed once the end date is in the past. When either transition fires, the job performs exactly the same recording the manual edit does — same country match, same airport add (server/jobs/tripStatusTransition.ts).

Which means: if you never touch the trip again after creating it as planned, the app will still record it correctly on its own — just not instantly.

The honest part: there's a lag

The status job runs once every 24 hours. If your flight lands at 6 a.m. and your trip's start date is today, the earliest that trip can flip to ongoing on its own is whenever the job next runs — which could be minutes away or most of a day away, depending on when in the cycle you land. Nothing about this is a bug to report; it's the cost of a daily batch job instead of a real-time one, and for a travel record (not a live GPS feed) that trade-off is the right one. If you want your airports to show up the moment you land, the fix is simple: open the trip and change its status yourself, or just create it as completed if you're logging it after you're already home. Editing the status is what makes the recording happen immediately rather than waiting for the next daily pass.

This is worth knowing before you assume the app lost your flight. It didn't. It just hasn't run its once-a-day check yet.

Idempotent by design, so editing twice is safe

The job and the manual routes call the exact same recording logic, and that logic is written to be safe to run more than once. If a trip jumps straight from planned to completed — say its end date was already in the past by the time you first saved it — the completion pass records the country and airports on its own, without needing a separate ongoing step first. And if a trip was already ongoing and had its airports recorded, running the same recording again on completion doesn't create duplicates; adding an airport or marking a country visited is written to be a no-op the second time (server/jobs/tripStatusTransition.ts). You will never end up with two departure records for the same flight because the job and a manual edit both happened to touch the trip.

Editing an active trip keeps your airports in sync

This part surprises people in the other direction: once a trip is ongoing or completed, editing its transport details doesn't just add the new airport — it also removes any airport tied to that trip that's no longer one of its current origin, destination, or layover slots. Change a layover from Doha to Istanbul on a trip that's already active, and the app drops the Doha record for that trip and adds Istanbul in its place (server/routes/trips.ts). A trip's recorded airports always reflect what the trip currently says, not what it said at some point in its history.

Cancelling a trip goes further still. Set an active trip's status to cancelled and the app removes every airport it had recorded for that trip specifically — not just stops adding new ones. If you logged a trip, flagged it ongoing, and later cancelled it because plans fell through, your airport log won't be carrying a flight you never actually took.

Where the free-tier airport cap fits in

There's one more quiet interaction worth knowing if you're on the Free plan, capped at 10 recorded airports. When a trip's status change tries to record an airport and you're already at the cap, the add is silently skipped — the trip still saves, the status still changes, you just don't get a new airport entry for it (server/lib/airportLimit.ts). Nothing errors, nothing warns you in the moment; the airport simply doesn't appear. If your flight count on a trip looks short and you're near the cap, that's very likely why, and Pro removes the limit rather than raising it.

What a planned trip looks like in the meantime

None of this hides the trip from you. A planned trip still shows up in your trip list, with its dates, transport details and destination exactly as you entered them — you can open it, edit it, attach a cover photo, add tasks and notes, all before it "starts" in the status sense. What it won't do is show up anywhere that's built from recorded visits: the destination country stays its current colour on the map, the origin and destination airports don't appear in your airport log, and any stats built from visited places or airports won't count it. The trip exists; the record of having actually gone doesn't, yet. That distinction is the whole point — a list of plans and a record of a life are two different things, and MapMyWorld tries hard not to let the first one quietly become the second just because you wrote it down early.

Why bother getting this right

None of this is complicated in isolation — a status field, a daily job, a bit of sync logic. What it adds up to is a record that only ever reflects trips you've actually confirmed happened, recorded at the moment they became real rather than the moment you first thought about them. A travel history retroactively logged years after the fact and a trip logged while you're still on it go through the same gate, just at different points on the calendar. And the airport log that this all feeds into is only useful if it means "airports I have actually been to" — not "airports attached to a plan I once made."

If you've been staring at a map that hasn't updated after a trip, the fix takes ten seconds: open the trip, confirm its status is ongoing or completed, and everything records the moment you save. You don't need to wait for tomorrow's job run, and you don't need to file a bug report — the map was just waiting for you to say the trip actually happened.