GTFS Static File Management: Taking Over a Schedule

Someone else built your agency's GTFS schedule file, and now it's yours. A planner retired, an IT staffer moved departments, or the duty arrived bundled with three others when the org chart shifted.

The file is probably still being published for consumption, which tells you less than it seems to. What you don't have is any picture of its condition, and you can't get one until you know all the pieces and how to produce it.

Taking over GTFS static file management breaks into four phases: take custody, assess what you inherited, set up the process you'll run, and work out what keeping it current will take.

What GTFS Static File Management Actually Involves

Your GTFS file is a zip file holding plain text tables: your stops, your routes, your trips, and the time each trip serves each stop. That's the whole artifact. It's small, it's readable, and it's the only description of your schedule that other systems can use.

Three kinds of consumers read it. Trip planners like Google Maps and Apple Maps. Aggregators that redistribute transit data to smaller applications. And your own station displays and mobile apps. None of them has another source for your schedule, which is what makes this file operational rather than administrative.

You'll also encounter GTFS Realtime, a separate live feed carrying vehicle positions, delays, and service alerts. Static describes what's supposed to happen. Realtime describes what's happening now, and it references the identifiers in your static file to do it.

GTFS static file management is the work of keeping that file accurate and available: authoring it when service changes, validating it, versioning it, and publishing it where consumers can fetch it.

Phase 1: Take Custody

Everything after this depends on holding the actual artifact and being able to change it. You may well have more than one copy in circulation, including a working file someone edits, an older copy sitting on a server, and the one consumers actually fetch. They aren't always the same file.

1. Find the file the outside world reads. Start with the link your agency publishes, then cross-check it against the GTFS weblink the Federal Transit Administration (FTA) holds for you in the GTFS Weblinks dataset on data.transportation.gov. If those two disagree, or either one resolves to something stale, you've found a problem before opening a single file.
2. Find what produces it. A vendor platform, an export from your scheduling system, a script somebody wrote, or hand-edited text files. This one answer determines how difficult every later phase will be.
3. Get access to all of it. The hosting location, the authoring tool, any vendor account, and your agency's login for the NTD reporting system at faces.fta.dot.gov. Access that lived entirely with the person who left is the most common gap at this stage.
4. Collect the paperwork and the names. The vendor agreement, the vendor's technical contact, and whoever published last. You're not evaluating terms yet. You're confirming they exist and that you can find them.

Phase 2: Assess What You Inherited

Once you can reach the file and change it, find out what condition it's in. Work from the cheapest check to the most involved, and record what you find rather than stopping to fix things. Repairs are easier to prioritize once you can see the whole picture.

1. Check when the GTFS static file expires. Open calendar.txt and find the latest end date. GTFS Schedule Best Practices, maintained by the nonprofit MobilityData, calls for a published dataset to reach at least 7 days into the future and cover 30 days of service where possible. Past its final date, your file describes no service at all.
2. Run the validator. MobilityData maintains the Canonical GTFS Schedule Validator, and the browser version takes minutes. It checks your file's structure and formatting against the specification, so treat errors as blocking and warnings as things to note.
3. Compare the file's stop times against your published timetable. Pick three trips across different routes and service days, then read the times in the file against the schedule your riders see.
4. Check whether realtime still joins to it. If you run a GTFS Realtime feed, confirm its trip IDs still appear in your static trips.txt. Caltrans, California's state transportation department, calls for 100% of trip IDs on planned trips to stay consistent between your static file and your realtime data, and when they don't, predicted arrival times stop resolving in apps and on your passenger information display systems.
5. Check whether it's reaching riders. Search your agency in the Mobility Database and in Transitland. Caltrans guidance on feed aggregators notes that absence from those two repositories can keep a provider out of trip-planning applications entirely.

Spend some time on the third check, because an out-of-date stop time is easy to overlook, and it causes the most rider frustration. Your platform signs, as well as any third-party tools, will display whatever time the file gives them, so a wrong time stays wrong until someone notices and edits the file.

Phase 3: Set Up the Process You'll Run

Fixing what you found doesn't keep the file accurate. Service will change again, and the file only stays current if something in your process reliably makes that happen.

1. Fix the publishing setup. One stable URL on your agency's domain, with no date or version number in the path, plus an archive of previous versions so you can roll back a bad publish. Caltrans is explicit that uploading to the Google Transit Partner portal doesn't satisfy a stable URL requirement. If hosting is your obstacle, the National Rural Transit Assistance Program will host GTFS data for any NTD reporter, rural or not.
2. Build the update trigger. Decide who tells you when service changes, and how far ahead. FTA expects your GTFS to be updated whenever service changes but sets no fixed deadline, and treats long-term route changes as reportable while short detours generally aren't. California's guidelines call for a week's notice, and GTFS Schedule Best Practices recommends expressing anything landing inside 7 days through your realtime feed instead.
3. Write the runbook. How to author, validate, publish, and roll back, in enough detail that a colleague could run it without you. This is the step that keeps your successor out of the position you're in right now.
4. Calendar the recurring obligations. Since Report Year 2023, FTA has required fixed-route National Transit Database reporters to maintain a public domain GTFS dataset and to certify annually that the link is viable and current. FTA's July 2025 final notice makes shapes.txt mandatory from Report Year 2025 for full reporters and Report Year 2026 for reduced, rural, and tribal reporters.

Phase 4: Work Out What Keeping It Current Will Take

Your findings tell you what to repair. They also tell you why the file drifted in the first place, and that second answer is the more useful one, because it predicts whether the same thing happens again next year.

Those four causes point at different remedies, and they resolve into the same two questions. How often does your service actually change, and can someone turn a change into a validated, published file before it takes effect? Cadence and capacity. What it costs follows from those, rather than deciding them.

Two schedule changes a year and a written routine is a manageable position. Frequent route changes and one undocumented spreadsheet is a real gap, and no budget line closes it on its own.

Where the Four Phases Become One Workflow

That gap is usually structural rather than financial. Scheduling owns the service change, IT owns the hosting, and whoever runs the signs finds out last. Most of what we take on is closing those handoffs, so a schedule change moves in one motion instead of three.

Fewer Steps Between a Service Change and a Sign

Our XT-PIDS platform handles the schedule and the displays in one place, so your file and what riders see stay in step by default rather than by coordination.

• One system, not three handoffs: static GTFS and realtime both move through the same Integrated Management System, so an update reaches your signs without a relay between teams.
• A schedule builder, not text files: updates run through an interface rather than hand-edited .txt files.
• Published versions archived: what goes out is retained, so you're not reconstructing last month's file from memory.
• Hosting handled: a stable URL on your own domain that we configure and maintain, rather than a ticket you chase every time service changes.

A Process That Survives a Staff Change

Phase 1 usually turns up access that lived with one person. Responsibility can sit with a team instead of an individual, which is what turns a routine into a process.

Take Control of Your GTFS Static File with XenaTech

You now know what your file needs, how often it will need it, and why it drifted in the first place. If your cadence outruns your capacity, the next decision is what you keep in-house and what you hand off. That is a much shorter conversation once your findings are written down.

Bring us your findings and let's work out what your file actually needs. Contact us to start the conversation.

Key Takeaways

• Take custody before assessing anything. Find the file consumers actually read, learn how it is produced, and secure access before evaluating condition.
• A file that publishes and validates cleanly can still be inaccurate, because validation checks how the file is built rather than whether its times match the service you run.
• Static accuracy sets the ceiling for realtime accuracy, because realtime references the identifiers and schedule in your static file.
• GTFS Schedule Best Practices calls for a dataset that is valid at least 7 days out and covering 30 days of service, published to a stable URL on your own domain.
• FTA has required a public GTFS dataset from fixed-route National Transit Database reporters since Report Year 2023, with annual certification that the link still works, and shapes.txt becomes mandatory in Report Year 2025 for full reporters.
• What your findings reveal about why your static file drifted matters more than the repair list, because the cause determines whether it drifts again.

Frequently Asked Questions

Is Publishing GTFS Required, or Is It Optional?

Required for fixed-route service. Since Report Year 2023, FTA has required National Transit Database reporters operating fixed route modes to create and maintain a public domain GTFS dataset reflecting that service, and to certify annually that the link is viable and current. Demand-response and paratransit service sits outside that requirement, though both carry separate NTD reporting obligations of their own. When we take on a file, that certification is one of the first things we check.

How Often Does a GTFS File Need Updating?

Whenever your service changes. Beyond that, publish often enough that the file always stays valid at least 7 days into the future. GTFS Schedule Best Practices treats 30 days of forward coverage as the target where you're confident in the schedule. An agency with two seasonal changes a year and one making frequent route changes need very different routines to meet the same standard, which is why we start by mapping your real change calendar.

What Happens if Our GTFS File Expires?

Your service stops appearing in trip planners. Once the last date in calendar.txt passes, the file no longer describes any service, so applications reading it have nothing to show riders. GTFS Schedule Best Practices also calls for removing expired calendars from the file. An expired file is the first thing we look for when we take one over, and it usually means the update trigger failed some time ago.

Does an Agency Own Its GTFS File if a Vendor Built It?

It depends entirely on your contract, which is why it's worth reading before you need it. Ownership of the source files, the right to have them returned when the agreement ends, and open GTFS publication all belong in writing. When we take on file management, we want that settled at the start, because a feed you can't take with you isn't fully yours.