Realtime validation errors and warnings

This page provides a list of validation errors and warnings for the Realtime Transit feed, as well as tips on how to troubleshoot these issues.

Realtime validation errors

To provide accurate information to passengers, be sure to fix any validation errors in your Realtime feed.

To debug the Realtime validation errors, use the information from the following table.

The "Enum value" column provides the short name of the issue in your Realtime feed, which displays in the validation report in the Transit Partner Dashboard.
The "Error message" column provides the message that displays in the validation report in the Transit Partner Dashboard. It summarizes the error.
The "Troubleshooting tips" column provides the major steps you need to take to resolve the error.

Enum value	Error message	Troubleshooting tips
`PROTO_MISSING_FIELDS_ERROR`	Binary protocol buffer is missing field(s) `%(field)`.	Open the file in a text editor and verify that the feed includes all of the fields marked as Required in the `FeedMessage` protocol buffer.
`PROTO_ASCII_ERROR`	Cannot parse ASCII protocol buffer. Errors: `%(field)`.	Open the file in a text editor and verify that the feed includes all of the required fields and uses the correct syntax.
`PROTO_PARSE_ERROR`	Cannot parse binary protocol buffer.	Open the file in a text editor and verify that the feed can be parsed as a `FeedMessage`. You can find code examples at Feed examples.
`URL_DNS_ERROR`	DNS error for URL.	Verify the internet connection and DNS settings.
`FETCHER_CONNECTION_ERROR`	Failed to connect to URL.	Verify the URL that you provided for fetching. Make sure the URL is correct.
`CUSTOM_PARSE_ERROR`	Failed to parse the custom-format feed: `%(value_string)`	Verify the file content in a text editor. Confirm that the file generates correctly and isn't corrupted during transport. If the error persists, reach out to your Google Transit representative for help.
`FEED_TOO_OLD`	Feed timestamp `%(timestamp)` (`%(timestamp_string)`) is in the past by `%(diff_time)` seconds (`%(difftime_string)`). The current time is `%(localtime)` (`%(localtime_string)`). Feed discarded.	Verify that there are no other problems reported about fetching the feed. Generate the feed regularly and keep data fresh. Ensure that the feed timestamp correctly represents the feed creation time in seconds after epoch (in UTC timezone).
`FETCHER_HTTP_ERROR`	HTTP Error: `%(value)`.	Verify the HTTP error code returned and investigate the issue accordingly.
`FULL_DATASET_REQUIRED`	Only `FULL_DATASET` feeds are supported.	Set the value of `incrementality` to `FULL_DATASET`.
`FEED_TIMESTAMP_CONSISTENTLY_IN_THE_FUTURE`	The feed timestamp is consistently in the future by `%(diff_time)` seconds (`%(difftime_string)`).	Be sure to provide the timestamp in the UTC timezone, in seconds after epoch. Check your server’s clocks to make sure that they're all synchronized, such as with NTP.
`INVALID_TIMESTAMP_RANGE`	The feed timestamp value is out of range (`%(timestamp)`).	Provide a feed timestamp that represents the feed creation time in seconds after epoch (in UTC timezone).
`PROTO_ENCODING_UNKNOWN`	Unknown feed encoding.	Use the correct encoding to configure the feed. Your final feed needs to be in binary format but you can use the ASCII format for testing.
`VEHICLE_POSITION_INTERNAL_ERROR`	`VehiclePosition` conversion into `TripUpdate` failed for `%(trip_id)` with a generic error "`%(value_string)`".	This error indicates that the `VehiclePosition` isn't used to estimate a `TripUpdate`. Contact your Google Transit representative for help.

Realtime validation warnings

To increase the feed data quality, it’s important to fix the validation warnings that indicate potential issues with your Realtime feed.

To debug the Realtime validation warnings, search through the entries in the following table.

The "Enum value" column provides the short name of the issue in your Realtime feed, which displays in the validation report in the Transit Partner Dashboard.
The "Warning or info message" column provides the message that displays in the validation report in the Transit Partner Dashboard. It summarizes the warning or information.
The "Troubleshooting tips" column provides the major steps you need to take to resolve the warning.

Enum value	Warning or info message	Troubleshooting tips
`TRIP_UPDATE_SOME_STU_NOT_MATCHED`	`%(value)` of valid `StopTimeUpdates` specified `trip_id` "`%(trip_id)`" were unable to be matched against the GTFS trip. e.g. position: `%(index)` stop_sequence: `%(next_seq)` `stop_id`: "`%(stop_id)`".	Make sure that the `StopTimeUpdates` are provided in the correct order.
`VEHICLE_POSITION_DUPLICATE_TRIP_BLOCK_TRANSFER`	A block transfer trip `$(trip_id)` and `start_time` `$(timestamp_string)` reported by multiple vehicles.	Ensure that only one vehicle represents a trip at a specific start time.
`INVALID_ALERT_ROUTE_NOT_MATCHED`	Alert discarded: `route_id` "`%(route_id)`" could not be matched to GTFS feed.	Verify whether the static schedule is correct and add the route information if it's missing. When the new static schedule is live, correct the `route_id` reference in the Realtime feed.
`INVALID_ALERT_STOP_NOT_MATCHED`	Alert discarded: `stop_id` "`%(stop_id)`" could not be matched to GTFS feed.	Verify whether the static schedule is correct and add the stop information if it's missing. When the new static schedule is live, correct the `stop_id` reference in the Realtime feed.
`INVALID_ALERT_TRIP_NOT_MATCHED`	Alert discarded: `trip_id` "`%(trip_id)`" could not be matched to GTFS feed.	Verify whether the static schedule is correct and add the trip information if it's missing. When the new static schedule is live, correct the `trip_id` reference in the Realtime feed.
`STOP_TIME_UPDATE_PREMATURE_ARRIVAL`	Arrival of `StopTimeUpdate` for trip "`%(trip_id)`" with `stop_id` "`%(stop_id)`" and `stop_sequence` `%(next_seq)` is `%(value)` seconds earlier than previous `StopTimeUpdate` with `stop_id` "`%(other_id)`" and `stop_sequence` `%(prev_seq)`.	Review the arrival time and departure time for the given `stop_id` or the previous ones. Fix the incorrect values to ensure that the times don't decrease.
`INVALID_ALERT_NO_INFORMED_ENTITIES`	At least one informed entity should be given.	Include a relevant `informed_entity` in the alert.
`PROTO_ENCODING_MISMATCH`	Configured proto encoding differs from received encoding.	Provide the feed in the correct format. If the problem persists, reach out to your Google Transit representative for help.
`STOP_TIME_UPDATE_PREMATURE_DEPARTURE`	Departure of `StopTimeUpdate` for trip "`%(trip_id)`" with `stop_id` "`%(stop_id)`" and `stop_sequence` `%(next_seq)` is `%(value)` seconds earlier than previous `StopTimeUpdate` with `stop_id` "`%(other_id)`" and `stop_sequence` `%(prev_seq)`.	Review the departure time for the given `stop_id` or the previous ones. Fix the incorrect values to ensure that the departure times don't decrease.
`DETOUR_MUST_SPECIFY_TIME`	Detour of trip "`%(trip_id)`" through stop "`%(stop_id)`" must specify absolute time.	Include the exact times at the affected `stop_id` for the specified `trip_id`.
`ENTITY_MUST_HAVE_ALERTS`	Entity must have alerts.	Verify that the feed content is complete and that each `FeedEntity` message includes information about service alerts.
`ENTITY_MUST_HAVE_POSITIONS`	Entity must have positions.	Verify that the feed content is complete and that each `FeedEntity` message includes vehicle position information.
`ENTITY_MUST_HAVE_UPDATES`	Entity must have trip updates.	Verify that the feed content is complete and that each `FeedEntity` message includes information about trip updates.
`TIMESTAMP_FUTURE`	Feed timestamp `%(timestamp)` (`%(timestamp_string)`) is in the future by `%(diff_time)` seconds (`%(difftime_string)`). Using the acquisition timestamp which is `%(localtime)` (`%(localtime_string)`).	Be sure to provide the timestamp in the UTC timezone, in seconds after epoch. Check your server's clocks to make sure that they're all synchronized, such as with NTP.
`TIMESTAMP_PAST`	Feed timestamp `%(timestamp)` (`%(timestamp_string)`) is in the past by `%(diff_time)` seconds (`%(difftime_string)`). Using the acquisition timestamp which is `%(localtime)` (`%(localtime_string)`).	Regenerate the Realtime feed more frequently, even if the content remains the same or empty.
`NO_VALID_TEXT`	Field `%(field)` has no valid translations.	Review the `TranslatedString` messages and fix any relevant issues, such as `HTML_TAGS_FOUND`, `INVALID_URL_LENGTH`, `INVALID_TEXT_LENGTH`, and `INVALID_URL`.
`HTML_TAGS_FOUND`	Field `%(field)`(`%(index)`) contains HTML tags.	Remove any HTML tags from the field.
`INVALID_LANGUAGE`	Field `%(field)`(`%(index)`) has invalid language code "`%(language)`".	Set the language field to a valid BCP-47 language code.
`INVALID_URL`	Field `%(field)`(`%(index)`) has invalid URL (absolute http or https expected).	Include a valid URL for the alert.
`INVALID_TEXT_LENGTH`	Field `%(field)`(`%(index)`) has length `%(length)` (maximum `%(max_length)`).	Shorten the supplied text, which often shows on small screens, such as mobile phones. If you want to provide more details to the users, provide a URL reference instead.
`INVALID_URL_LENGTH`	Field `%(field)`(`%(index)`) has URL length `%(length)` (maximum `%(max_length)`).	Provide a URL that fits within the limits.
`MULTIPLE_UNSPECIFIED_LANGUAGE`	Field `%(field)`(`%(index)`) is a repeated translation with no language set.	Review the `TranslatedString` messages. Set correct values for the `language` field where more than one translation is given.
`INVALID_TRIP_UPDATE_DELAY`	Invalid delay within trip update: `%(value)`.	Review the `delay` field of the given `entity_id` and fix the incorrect value.
`INVALID_TRIP_UPDATE_EVENT_TIME`	Invalid stop event time: `%(timestamp)`.	Include `TripUpdates` only for trips that are ongoing or occurring in the near future.
`INVALID_TRIP_UPDATE_DEPARTURE_NO_TIME`	Neither `time` nor `delay` provided for a departure.	Include a `time` field, a `delay` field, or both at each `StopTimeEvent` message. If no information is available, omit the `departure` field.
`INVALID_TRIP_UPDATE_ARRIVAL_NO_TIME`	Neither `time` nor `delay` provided for an arrival.	Include a `time` field, a `delay` field, or both at each `StopTimeEvent` message. If no information is available, omit the `arrival` field.
`MISSING_CONTENT_AND_EFFECT`	No valid content or effect.	Add `effect`, `header_text`, or `description_text` into the alert. If no information is available, remove the `alert` instead.
`CUSTOM_PARSE_WARNING`	Partial failure when parsing the custom-format feed: `%(value_string)`	This error indicates a portion of the Realtime feed wasn't able to be parsed. Open a text editor to verify the feed's content, or reupload the feed. If the error persists, contact your Google Transit representative for help.
`VEHICLE_POSITION_BAD_START_TIME`	Specified trip `$(trip_id)` start time is `%(diff_time)` seconds away from actual start of the vehicle.	Specify the start time of the vehicle close to the actual start time of the trip.
`INVALID_TRIP_UPDATE_INCONSISTENT_IDS`	`stop_sequence` `%(value)` does not match stop "`%(stop_id)`" for trip "`%(trip_id)`". Overriding it with the `stop_sequence` `%(next_seq)` from the static index.	Ensure that the value of `stop_sequence` field is correct and matches the `stop_sequence` for the same `stop_id` and `trip_id` in the current static feed.
`INVALID_STOP_STOP_ID`	`StopTimeUpdate` discarded: `stop_id` "`%(stop_id)`" given for trip "`%(trip_id)`" could not be matched to GTFS feed. `stop_sequence` [if present] `%(value)`.	Verify the accuracy of the static feed. If needed, fix the value of `stop_id` in `stop_times.txt` for the trip. Wait until the new version of the static feed is live. Update the `stop_id` reference in the Realtime feed.
`INVALID_STOP_SEQUENCE_ID`	`StopTimeUpdate` discarded: `stop_sequence` `%(value)` within trip "`%(trip_id)`" could not be matched to GTFS feed.	Verify the accuracy of the static feed. If needed, fix the value of `stop_sequence`. Wait until the new version of the static feed is live. Update the `stop_sequence` reference in the Realtime feed.
`INVALID_TRIP_UPDATE_ORDER`	`StopTimeUpdate` discarded: `stop_sequence` order violation for `trip_id` "`%(trip_id)`" `stop_id` [if present] "`%(stop_id)`", `stop_sequence` `%(prev_seq)` followed by `%(next_seq)`.	Be sure to set the order of `StopTimeUpdates` with `stop_sequence`.
`FEED_TIMESTAMP_CONSISTENTLY_IN_THE_PAST`	The feed timestamp is consistently in the past by `%(diff_time)` seconds (`%(difftime_string)`).	Confirm that the timestamp value is in UTC timezone, in seconds after epoch. Confirm that your server's clocks are synchronized, such as with NTP. Be sure to update the feed regularly.
`TIMESTAMP_MISSING`	The feed's `FeedHeader` is missing the `timestamp` field.	Fill in the `timestamp` field in the `FeedHeader` in seconds after epoch, in UTC timezone. The timestamp needs to correctly represent the feed generation time.
`ENTITY_MORE_THAN_ONCE`	The `FeedEntity`'s id appears more than once in the feed.	Ensure that all entity IDs are unique in the feed.
`PROTO_ASCII_HAS_BOM`	The provided feed begins with a Byte Order Mark (BOM).	Remove the Byte Order Mark. Ensure that the text-formatted protocol buffer is in UTF-8 without a BOM. We recommend that you provide the protocol buffer in binary format instead.
`TRIP_UPDATE_TIMESTAMP_CONSISTENTLY_IN_THE_FUTURE`	The `timestamp` for some trip update is consistently in the future by `%(diff_time)` seconds (`%(difftime_string)`).	Confirm that the `timestamp` value is formatted as a UTC timezone, in seconds after epoch. Confirm that your server's clocks are synchronized, such as with NTP. Remove `TripUpdates` from the feed for trips that were completed more than one hour ago.
`VEHICLE_POSITION_TIMESTAMP_CONSISTENTLY_IN_THE_FUTURE`	The timestamp is consistently in the future by `%(diff_time)` seconds (`%(difftime_string)`).	Confirm that the `timestamp` value is formatted as a UTC timezone, in seconds after epoch. Confirm that your server's clocks are synchronized, such as with NTP.
`VEHICLE_POSITION_TIMESTAMP_CONSISTENTLY_IN_THE_PAST`	The `timestamp` is consistently in the past by `%(diff_time)` seconds (`%(difftime_string)`).	Confirm that the `timestamp` value is formatted as a UTC timezone, in seconds after epoch. Confirm that your server's clocks are synchronized, such as with NTP. Remove `VehiclePositions` from the feed for trips that were completed more than one hour ago.
`UNKNOWN_TRIP_ID`	The trip id "`%(trip_id)`" is unknown to the static GTFS feed.	Verify the static feed to ensure that it contains correct and up-to-date information. Ensure that the correct version of the static feed is in use, or upload the correct version where necessary. Provide an existing and accurate `trip_id` in the `TripDescriptor`.
`TRIP_OUTSIDE_SERVICE_WINDOW`	The trip with id "`%(trip_id)`" is not in service at the specified time.	Verify the accuracy of the static feed. Add the trip information if it’s missing. Wait until the new version of the static feed is live. Correct the `trip_id` reference in the Realtime feed.
`AMBIGUOUS_TRIP_DESCRIPTOR`	The `TripDescriptor` is ambiguous, and does not resolve a single trip at a particular time.	If the trip is frequency based, be sure to provide a valid `start_time` value and a `start_date` value in `TripDescriptor`.
`INVALID_TRIP_UPDATE_FUTURE_TIMESTAMP`	The `TripUpdate` timestamp `%(timestamp)` (`%(timestamp_string)`) is in the future by `%(diff_time)` seconds (`%(difftime_string)`) when compared to the feed timestamp which is `%(localtime)` (`%(localtime_string)`).	Verify that the clock source has the correct time set. Verify that any timezone conversions are performed accurately. The `Vehicle.Position.timestamp` field needs to be formatted as a UTC timezone, in seconds after epoch.
`INVALID_VEHICLE_POSITION_FUTURE_TIMESTAMP`	The `VehiclePosition` timestamp `%(timestamp)` (`%(timestamp_string)`) is in the future by `%(diff_time)` seconds (`%(difftime_string)`) when compared to the feed timestamp which is `%(localtime)` (`%(localtime_string)`).	Verify that the clock source has the correct time set. Verify that any timezone conversions are performed accurately. The `Vehicle.Position.timestamp` field needs to be formatted as a UTC timezone, in seconds after epoch.
`INVALID_VEHICLE_POSITION_STALE_TIMESTAMP`	The `VehiclePosition` timestamp `%(timestamp)` (`%(timestamp_string)`) is in the past by `%(diff_time)` seconds (`%(difftime_string)`) when compared to the feed timestamp which is `%(localtime)` (`%(localtime_string)`).	Remove the out-of-service vehicles from the feed. Verify that the clock is synchronized and the timezone conversions are correct.
`INVALID_ALERT_TIME_RANGE_END_PAST`	Time range ended over a month ago: `%(time_end)`.	Remove alerts (or `active_periods`) which have the end time in the past and are no longer active.
`INVALID_ALERT_TIME_RANGE_ORDER`	Time range order is reversed: (`%(time_start)`, `%(time_end)`).	Verify the value of the `active_period` fields. The order of these fields might be reversed.
`INVALID_ALERT_TIME_RANGE_START_FUTURE`	Time range starts more than a year from now: `%(time_start)`.	Include an `active_period` start time in the near future into the alerts.
`STOP_TIME_AND_DELAY_MISMATCH`	Trip "`%(trip_id)`" at stop "`%(stop_id)`" specifies timestamp `%(timestamp)` and delay `%(delay)` which contradict each other. Setting delay to `%(value)`.	Verify that the Realtime feed matches the currently live static feed. Make sure that the `delay` field and `time` field in `StopTimeEvent` are correct and consistent. Alternatively, omit the `delay` field entirely and provide only the `time` field instead.
`INVALID_START_DATE`	Trip "`%(trip_id)`" has invalid start date "`%(value_string)`", assuming today. Expected format is "YYYYMMDD".	Verify the value of the start_date for the specified trip. Ensure that the value is correct.
`INVALID_START_TIME`	Trip "`%(trip_id)`" has invalid start time "`%(value_string)`". Expected format is "HH:MM:SS".	Verify the value and format of the `start_time` for the specified trip. Ensure that the value and the format are correct.
`VEHICLE_POSITION_DUPLICATE_TRIP`	Trip `$(trip_id)` and `start_time` `$(timestamp_string)` reported by multiple vehicles.	Change the `start_time` of the trip and change the `ScheduleRelationship` to `ADDED` for the non-frequency based trips.
`VEHICLE_POSITION_CONVERTED_TO_ADDED`	Trip `$(trip_id)` schedule relationship was changed to `ADDED` trip.	This error is the side effect of another problem. Address that problem first to fix this error.
`INVALID_TRIP_UPDATE_MISSING_IDS`	Trip update contains `stop_update` with neither `stop_sequence` nor `stop_id`.	Include a `stop_id`, a `stop_sequence`, or both into the `StopTimeUpdate` message.
`MULTIPLE_ENTITIES_PER_TRIP`	Trip update discarded: Represents the same `trip_id` "`%(trip_id)`" with the same start time as other entity with id `%(value_string)`.	Ensure that there's at most one `TripUpdate` for each real-world journey. Ensure that the `TripDescriptor` is unique within the feed.
`INVALID_TRIP_UPDATE_MISSING_CONTENT`	Trip update for scheduled `trip_id` "`%(trip_id)`" should specify at least one stop time update with data or specify a delay.	Provide one of the following: `StopTimeUpdate` with data `TripUpdate.delay`
`TRIP_UPDATE_SUSPICIOUS_DELAY`	Trip with `trip_id` "`%(trip_id)`" contains a suspiciously unreasonable delay of `%(difftime_string)`.	Verify that the `TripDescription` is clearly defined, which needs to have a `trip_id`, `start_date`, and `start_time`. Verify that `StopTimeUpdates` have time values that match the specified trip. Check for any timezone mismatch problems, for example, whether `start_date` and `start_time` are in the local timezone, but all integer time fields in `FeedMessage` are in seconds after epoch.
`TRIP_UPDATE_OBSOLETE`	Trip with `trip_id` "`%(trip_id)`" ended `%(difftime_string)` ago.	Remove trips from the feed a few minutes after they reach the final stop.
`UNSUPPORTED_ADDED_WITH_BLOCK_TRANSFER`	`TripDescriptor` with a `schedule_relationship` of `ADDED` for a trip `%(trip_id)` with a block transfer is not supported.	Only use the `ADDED` value for `ScheduleRelationship` to indicate the isolated trips.
`UNSUPPORTED_ADDED_WITHOUT_TIMES`	`TripDescriptor` with a `schedule_relationship` of `ADDED` for a trip `%(trip_id)` without times specified.	Provide a `start_date` and a `start_time` to indicate when the added trip began.
`TRIP_UPDATE_TOO_OLD`	`TripUpdate` timestamp `%(timestamp)` (`%(timestamp_string)`) is in the past by `%(diff_time)` seconds (`%(difftime_string)`). The current time is `%(localtime)` (`%(localtime_string)`). `TripUpdate` discarded.	Generate the feed regularly and keep data fresh. Ensure that the `TripUpdate` timestamp is correct, in seconds after epoch, and formatted as a UTC timezone. Remove trips from the feed a few minutes after they reach the final stop.
`INVALID_TRIP_UPDATE_DELAY_USAGE`	`TripUpdate`'s `delay` field specified together with time in `StopTimeUpdates`.	Provide timing information using only one of the following, instead of both: `StopTimeUpdates` `TripUpdate.delay`
`INVALID_VEHICLE_POSITION_VEHICLE_ID_MISSING`	`VehiclePosition` lacks a vehicle identifier.	Provide a vehicle identifier. Make sure this value is stable across all versions of the feed in which the vehicle is in service.
`INVALID_VEHICLE_POSITION_INVALID_POSITION`	`VehiclePosition` lacks valid position information.	Provide valid values for the `latitude` and `longitude` fields.
`INVALID_VEHICLE_POSITION_TIMESTAMP_MISSING`	`VehiclePosition` timestamp is missing.	Provide a timestamp value of when the `VehiclePosition` information was collected, in seconds after epoch formatted as a UTC timezone.