Uploading a new GTFS: GTFS Intake for the Swiftly Dashboard

Need to update your GTFS schedule in Swiftly due to a service change, unexpected event or issue with your GTFS? Swiftly's GTFS intake tool has you covered.

Overview of our GTFS Intake Process

You can access the Swiftly GTFS management tool under Admin > GTFS tools on the bottom right-hand side navigation. 

Note: only users with GTFS management permissions can access this tool.

Automatic intake

If your GTFS intake process is automatic, we will scan the GTFS URL on file every few hours to detect a change in your static GTFS file. If a new file exists, Swiftly automatically uploads it. You can read more about this automatic process here.

Manual intake

Are you used to producing a zip file, but hosting a GTFS in a URL? Not a problem, you can manually upload your GTFS into Swiftly. Note, your GTFS settings need to be set to "Manual" in order to upload.

When using a manual upload, simply upload a zipped GTFS file directly from your computer to the GTFS Settings uploader. A description notating the GTFS updates is required for all manual file uploads.

Note: when you switch to manual upload, Swiftly will no longer automatically retrieve GTFS updates from the entered URL until it is changed back. Once automatic updates are turned back on, our system will update the GTFS if the files are different from those uploaded manually. If they are the same, our system will not upload a new GTFS. 

Going live

If the upload is successful, your GTFS will be set to "Future" status and go live on:

• 3:30am local time of day of your next active service period in your GTFS calendar file. 
  
  Ex: if GTFS service starts 1/1/2026, and you upload on 12/25/2025, the file will not go live until 3:30am local time on 1/1/2026.
   
• Or, if you use the feed_info.txt file, the file will go live on the next active date on the feed_start_date field.

Note: if the GTFS service is already active, but uploaded after the active service date, the file will go live on the following service day. Swiftly’s static GTFS and GTFS real-time features are designed to maintain functionality through schedule transitions. The active static GTFS schedule remains operational through the last service day of the current schedule, and GTFS real-time features continue to function without interruption. After uploading the next GTFS file, Swiftly’s system automatically detects the new file and stages it to go live at the start of service on the new service date.
 

Urgent GTFS changes

If a GTFS needs to be published ASAP, and not overnight, please contact us at [e-mail]. We will work with you to try and update your GTFS right away.

FAQs About GTFS Intake

What time zone is listed in the GTFS tool?

Local time per your GTFS. For example, if your agency GTFS location is Los Angeles, the timezone will be Pacific Time.

How long does it take for a GTFS file to process if uploaded?

It can take anywhere from 15 minutes to an hour for an uploaded GTFS to process successfully. Remember, after a GTFS is processed, it won't go live until 3:30am local time the next morning (unless you email [e-mail] to publish immediately).

What is the process behind the scenes for intaking new GTFS?

When the system detects a change to your GTFS files, it requires a reboot to your agency's dashboard. Rebooting means that your dashboard will be down for a few minutes. Because of this outage, processing and intaking a new GTFS file will happen late at night there is no transit service. We do this to avoid any dashboard problems during peak service hours. 

How do I tell what version of our GTFS is being used right now?

In  GTFS Intake Log, the active GTFS version will be labeled with "Current" in a separate section above "All Schedules".

Best Practices for GTFS File Updates

• Regularly review and update GTFS files to reflect accurate schedules.
• Clearly define service periods to avoid overlaps or gaps in schedule coverage.
• Test new GTFS files in a staging environment before deploying them to production. By adhering to these best practices, you can ensure that your GTFS files are well-managed and that service continuity is maintained during schedule transitions.
• Handling Overlapping Schedule Periods
  • When managing overlapping schedule periods, it is recommended to use a single GTFS file that clearly distinguishes between schedules using service dates in calendar.txt and/or calendar_dates.txt. Follow these steps:
    • Define Distinct Service IDs: Assign unique service_id values for each schedule period (e.g., current and upcoming schedules).
    • Set Appropriate Dates: Specify the start and end dates for each service_id to ensure that schedules are correctly applied to their respective timeframes.
    • Avoid Combining Feeds: Do not merge separate schedules into a single GTFS feed that duplicates routes. This can lead to confusion and errors in schedule representation. By following this approach, systems like Swiftly can accurately read and display the correct schedule for each period without overlap or duplicate route names. Once the new schedule period begins and the old one is deprecated, publish a clean GTFS file containing only the active schedule.