RailBat

Real-time rail delay predictions

Real-time Rail Delay Predictions provides a live data feed of predicted train lateness at future calling points. The service delivers continuously updated delay forecasts via a secure API, supporting passenger information, operational monitoring, and journey planning applications.

Features

• Live feed of predicted train delays
• Forecast lateness at future calling points
• Continuous updates based on latest available data
• API access to predictions and timestamps
• Filtering by service, route, station, or time window

Benefits

• Enables proactive disruption awareness
• Improves passenger information accuracy
• Supports operational and planning decisions
• Reduces surprise delays for end users

Service documents

• Pricing document

  ODT

• Service definition document

  ODT

• Terms and conditions

  ODT

Request an accessible format

If you use assistive technology (such as a screen reader) and need versions of these documents in a more accessible format, email the supplier at alex.clark@railbat.uk. Tell them what format you need. It will help if you say what assistive technology you use.

Framework

G-Cloud 15

Service ID

379267952481156

Contact

Alex Clark
07726914131
alex.clark@railbat.uk

About your service

• Service categories:

  Application Development and Deployment

  Analytics and business intelligence

  • Advanced and predictive analytics
• Multi cloud support: Yes

Service scope

• Software add-on or extension: Yes, but can also be used as a standalone service
• What software services is the service an extension to: Passenger information systems, journey planners, and operational dashboards can integrate the service to display predicted delays and support decision-making.
• Cloud deployment model: Private cloud
• Service constraints: The service is provided via API only and does not include an end-user interface. Predictions are indicative and provided for decision-support purposes only. Buyers cannot modify the underlying prediction logic. Planned maintenance may result in temporary service unavailability, with advance notice where possible.
• System requirements:
  • Secure internet connectivity for REST API access.
  • Ability to authenticate using API keys or tokens.
  • Secure storage of API credentials.
  • Ability to process JSON API responses.
  • Integration capability with downstream applications.
  • Support for TLS 1.2 or higher.
  • Logging and monitoring of API usage.
  • Ability to handle API rate limits.
  • Endpoint security on systems accessing the service.
  • Compliance with organisational security policies.

User support

• Email or online ticketing support: Yes, at extra cost
• Support response times: Standard support is provided by email with best-effort response, typically within 2 business days (Mon–Fri). Messages received at weekends or UK public holidays are responded to on the next working day.; Priority support (paid add-on) provides an initial response within 1 business day, with faster turnaround where possible.
• User can manage status and priority of support tickets: No
• Phone support: Yes
• Phone support availability: 9 to 5 (UK time), Monday to Friday
• Web chat support: No
• Onsite support: No
• Support levels: We provide two support levels:; ; Standard Support (included): Email support during UK business days (Mon–Fri). Best-effort response, typically within 2 business days. Queries received at weekends or UK public holidays are handled on the next working day.; ; Priority Support (paid add-on): Email support with an initial response target of 1 business day (Mon–Fri), with faster turnaround where possible. Suitable for time-sensitive questions and operational issues.; ; Pricing: Standard Support is included with the service. Priority Support is available as an additional monthly fee, quoted per customer depending on expected volume and required coverage.; ; Technical account manager / cloud support engineer: As an SME, we do not provide a dedicated technical account manager or cloud support engineer by default. However, customers have direct access to our technical team for support, guidance on setup, usage, and troubleshooting.
• Support available to third parties: Yes

Onboarding and offboarding

• Getting started: We help users get started through clear onboarding steps and self-service documentation. Users receive API credentials and guidance on how to authenticate, make their first request, and retrieve results in standard formats (for example JSON/CSV). We provide online API documentation, including endpoint descriptions, parameter guidance, example requests/responses, and common integration patterns. Basic troubleshooting information is included to help users resolve typical issues (for example authentication errors and rate limits). Support is available via email, with an optional paid priority support tier for faster response. We do not provide onsite training as standard, but remote onboarding sessions or tailored walkthroughs can be offered by agreement where required.
• Service documentation: Yes
• Documentation formats:
  • HTML
  • Other
• Other documentation formats: Code examples / sample requests
• End-of-contract data extraction: At the end of the contract, users lose access to the service and API credentials are revoked. The service is provided on an access-only basis and users are not permitted to retain or continue using the predictive data or service outputs after the contract ends, unless explicitly agreed in writing.
• End-of-contract process: At the end of the contract term, access to the service is terminated and API credentials are revoked, meaning users can no longer call the API or access service outputs. Offboarding guidance explains how to stop API usage, remove integrations from buyer systems, and confirm access has been disabled.
• Documentation accessibility standard: None or don’t know
• How the documentation is accessible: Onboarding and offboarding documentation is provided online in HTML and is written in a clear, structured format with headings, short sections, and plain language. The documentation is designed to be compatible with common browsers and assistive technologies, and usable with keyboard navigation. Where relevant, we provide copy-and-paste examples (for example API requests and responses) to support different ways of consuming the information. Offboarding guidance includes how to stop API usage, rotate or revoke credentials, and remove integrations from the buyer’s systems. If buyers require alternative formats or reasonable adjustments (for example a PDF copy or accessible text export), these can be provided on request.

Using the service

• Web browser interface: No
• Application to install: No
• Designed for use on mobile devices: No
• Service interface: Yes
• User support accessibility: None or don’t know
• Description of service interface: The service is delivered via a secure REST API that provides programmatic access to the live predictive delay data. Customers authenticate using API keys or token-based authentication and can query, filter, and retrieve results in standard machine-readable formats (for example JSON and CSV). The API is documented and designed to be used from common tools and programming languages. There is no end-user graphical interface; access is via API endpoints and supporting documentation.
• Accessibility standards: None or don’t know
• Description of accessibility: The service is accessed programmatically via a REST API (no graphical user interface). As an API, it is not directly used through visual layouts or interactive components, so WCAG user-interface requirements have limited applicability. Accessibility considerations are focused on the supporting materials: API documentation is provided in a clear, structured format, compatible with screen readers and assistive technologies, and designed to be usable with keyboard-only navigation. Users can authenticate and retrieve data via standard HTTP requests and receive responses in machine-readable formats (for example JSON/CSV). Users cannot interact with the service through a web portal or visual dashboard.
• Accessibility testing: The service is delivered via an API and does not include an end-user graphical interface, so there is no interactive UI to test with assistive technology users. Formal accessibility testing with screen readers or other assistive tools has not been completed for the API itself. We have reviewed the supporting API documentation for accessibility best practice, including clear structure (headings, lists), readable language, and compatibility with keyboard navigation and screen readers. If buyers require specific accessibility assurance, we can make reasonable adjustments to documentation and provide alternative formats on request.
• API: Yes
• What users can and can't do using the API: Users access live predictive delay data via a secure REST API. Setup is completed by issuing API credentials (for example an API key or token) and configuring the client application to authenticate and call the endpoints. Using the API, users can query and filter the dataset, retrieve results in standard machine-readable formats (for example JSON/CSV), and automate data retrieval in their own systems and workflows. Users can adjust request parameters (such as filters, pagination, and query options) to change the results returned.; Users cannot change the underlying dataset, create or edit records, or manage billing or user accounts via the API. Access is limited to authorised credentials and is subject to rate limits, usage controls, and agreed permissions. Some features may require additional enablement depending on the service plan.
• API documentation: Yes
• API documentation formats:
  • HTML
  • Other
• API sandbox or test environment: No
• Customisation available: Yes
• Description of customisation: Users can customise how they access and consume the dataset through the API. Customisation includes selecting query parameters (for example filters, date ranges, search criteria, fields returned, sorting, and pagination) to tailor the results to their use case. Users can also integrate the API into their own systems and workflows, and choose how often data is retrieved (for example scheduled polling within rate limits).; ; Customisation is performed by authorised buyer users and third parties acting on the buyer’s behalf, using valid API credentials and the published API documentation.; ; Users cannot customise or change the underlying dataset, data model, or core API behaviour. Any changes to service features, additional endpoints, or bespoke data extracts are subject to separate agreement and may incur additional cost.

Scaling

• Independence of resources: We use request throttling and per-customer rate limits to prevent any single user from consuming disproportionate capacity. The service is hosted on scalable cloud infrastructure with monitoring in place to manage performance and availability. Where necessary, we apply fair-usage controls (for example burst limits and queueing) to maintain consistent response times. These measures reduce the risk of one customer’s demand impacting others and help ensure predictable service for all authorised users.

Analytics

• Service usage metrics: Yes
• Metrics types: We provide basic service usage metrics to help customers monitor and manage consumption. Metrics include API request counts, response status/error rates (for example authentication failures and rate-limit responses), and usage over time. Where applicable, we can also provide high-level breakdowns by API key or client identifier to support operational monitoring and reporting.
• Reporting types: Reports on request
• Resource tagging: No
• FOCUS resource tagging: No

Resellers

• Supplier type: Not a reseller

Staff security

• Staff security clearance: Other security clearance
• Government security clearance: Baseline Personnel Security Standard (BPSS)

Asset protection

• Knowledge of data storage and processing locations: Yes
• Data storage and processing locations: United Kingdom
• User control over data storage and processing locations: No
• Datacentre security standards: Managed by a third party
• Penetration testing frequency: At least once a year
• Penetration testing approach: Another external penetration testing organisation
• Protecting data at rest:
  • Encryption of all physical media
  • Other
• Other data at rest protection approach: Data at rest is protected using encryption on storage volumes and backups (where applicable), with encryption keys managed securely by the hosting provider or via a managed key service. Access to stored data is restricted using least-privilege permissions and strong authentication, with audit logging for administrative access. Production systems are hardened and patched, and sensitive credentials are stored securely. Physical access controls to the underlying infrastructure are managed by the third-party hosting provider within a secured datacentre environment.
• Data sanitisation process: Yes
• Equipment disposal approach: A third-party destruction service
• Data sanitisation type:
  • Deleted data can’t be directly accessed / Cryptographic Erasure
  • Data Erasure

Data importing and exporting

• Data export approach: Users export data by retrieving it through the REST API using standard queries and filters, then saving the API responses within their own systems. Responses are provided in machine-readable formats (for example JSON and CSV) to support automated export and integration workflows. Export is limited to the data returned by authorised API requests and is subject to access permissions and rate limits. The service is access-only and buyers are not permitted to retain or continue using the dataset after the contract ends, unless explicitly agreed in writing.
• Data export formats:
  • CSV
  • Other
• Other data export formats: JSON
• Data import formats: Other
• Other data import formats: NA – service is read-only API).

Data-in-transit protection

• Data protection between buyer and supplier networks: TLS (version 1.2 or above)
• Data protection within supplier network: TLS (version 1.2 or above)

Availability and resilience

• Guaranteed availability: We aim to provide a reliable, continuously available API service and monitor availability and performance. Where agreed in the contract, we offer an availability SLA of 99.5% monthly uptime, excluding planned maintenance and events outside our reasonable control (for example upstream network failures or force majeure). Planned maintenance is scheduled where possible with advance notice.; ; If monthly availability falls below the agreed SLA, customers may request a service credit applied to the next invoice or contract period, calculated on a pro-rata basis for the affected month. Service credits are the customer’s sole remedy for SLA breaches unless otherwise agreed in writing. Availability measurement is based on successful API responses from our service monitoring.
• Approach to resilience: The service is designed for resilience through layered controls across infrastructure, application, and operations. It is hosted on third-party resilient infrastructure in a secured datacentre environment, with redundant power and networking and monitored physical security controls. At the service layer, the API is deployed using hardened, monitored systems with automated health checks, alerting, and controlled failover/restart procedures. Data is protected through regular backups (where applicable) and recovery processes to support restoration following incidents. Rate limiting and traffic controls help maintain stability during spikes in demand. We carry out routine patching and maintenance and schedule planned downtime where possible with advance notice. Further details of the datacentre resilience design and controls can be provided to buyers on request.
• Outage reporting: Outages and service degradation are monitored and communicated to customers through direct email notifications to nominated buyer contacts. Where possible, we provide advance notice of planned maintenance and any expected service interruption. For unplanned incidents, we issue an initial notification once confirmed, followed by periodic updates until service is restored, and a short incident summary on request. We do not currently provide a public status dashboard or a dedicated outage reporting API; outage information is shared via email and support channels.

Identity and authentication

• User authentication needed: Yes
• User authentication: Other
• Other user authentication: API key / bearer token authentication
• Access restrictions in management interfaces and support channels: Access to management functions is restricted to authorised personnel using least-privilege permissions. Administrative access is protected by strong authentication, limited to approved accounts, and logged for audit purposes. Support access is controlled by verifying the requester against nominated buyer contacts and using role-based access to limit what support staff can view or change. Sensitive actions (for example credential resets or access changes) require additional verification and are tracked. Credentials and secrets are stored securely and access is reviewed periodically to ensure permissions remain appropriate.
• Access restriction testing frequency: At least once a year
• Management access authentication:
  • Multi-Factor Authentication (MFA)
  • Identity federation with existing provider (for example Google Apps)
  • Other
• Description of management access authentication: Role-based access control / least privilege, e.g. IAM roles

Audit information for users

• Access to user activity audit information: Users contact the support team to get audit information
• How long user audit data is stored for: Between 6 months and 12 months
• Access to supplier activity audit information: Users contact the support team to get audit information
• How long supplier audit data is stored for: Between 6 months and 12 months
• How long system logs are stored for: Between 6 months and 12 months

Security governance

• Named board-level person responsible for service security: Yes
• Security governance certified: No
• Security governance approach: We follow a proportionate security governance approach aligned to recognised good practice. Security responsibilities are defined, access is controlled using least privilege and strong authentication, and changes are managed through documented processes. We maintain secure configuration, patching, monitoring, and incident response procedures. Risks are reviewed regularly and controls are updated as the service evolves. Supplier and hosting risks are considered as part of service delivery, and security requirements are included in contracts where applicable. Evidence and supporting documentation can be provided to buyers on request.
• Information security policies and processes: We follow documented information security policies and processes covering access control, authentication, secure configuration, vulnerability management, patching, encryption, logging/monitoring, incident management, and business continuity. Data handling rules define how information is stored, accessed, and shared, including least-privilege access and separation of environments where applicable. Changes to production systems follow a controlled change process with review and rollback procedures.; ; Security governance is overseen by senior management within the SME, with clear responsibility for security decisions and risk acceptance. Policies are communicated to relevant personnel and suppliers, and compliance is supported through access reviews, audit logs, secure credential management, routine monitoring, and periodic risk reviews. Security incidents and significant risks are escalated through the management reporting structure and handled using a documented incident response process.
• Software Security Code of Practice: Yes

Operational security

• Configuration and change management standard: Supplier-defined controls
• Configuration and change management approach: Service components (code, configuration, infrastructure) are tracked through their lifecycle using version control and documented environment configuration. Changes are implemented via a controlled change process, including peer review where applicable, testing in a non-production environment, and planned deployment/rollback procedures. Changes are assessed for security impact by reviewing authentication/authorisation, data access, logging, and any dependency updates. Access to production configuration is restricted to authorised personnel and changes are logged. Security patches and urgent fixes follow an expedited process with post-change review.
• Vulnerability management type: Supplier-defined controls
• Vulnerability management approach: We assess threats through regular review of service architecture, access controls, and dependencies, and by monitoring for abnormal behaviour and security alerts. Vulnerabilities are prioritised based on risk and exposure (for example internet-facing components, data sensitivity, and exploitability). Security patches are deployed as soon as practical: critical vulnerabilities are prioritised for expedited patching, with other updates applied through scheduled maintenance. Threat intelligence is sourced from vendor security advisories, dependency and OS update notifications, and trusted public sources (for example NCSC guidance and CVE disclosures). Remediation actions are tracked to completion and changes follow controlled deployment and rollback procedures.
• Protective monitoring type: Supplier-defined controls
• Protective monitoring approach: We use protective monitoring to identify potential compromise through centralised logging, automated alerts, and regular review of security-relevant events (for example authentication failures, unusual API usage patterns, privilege changes, and unexpected configuration changes). When suspicious activity is detected, we investigate promptly, contain risk by restricting access (for example disabling credentials or blocking traffic), and preserve logs for analysis. Incidents are managed through a documented response process, including remediation, recovery, and post-incident review. We aim to respond to confirmed security incidents within 1 business day, and sooner where critical service impact is identified.
• Incident management type: Supplier-defined controls
• Incident management approach: We follow a documented incident management process with pre-defined handling steps for common events (for example service outage, suspected credential compromise, and unusual API activity). Users report incidents via email to the support contact, with optional paid priority support for faster response. Incidents are logged, triaged by severity, and managed through containment, investigation, remediation, and recovery, with stakeholder updates provided during the incident. After resolution, we can provide an incident report on request, including impact summary, timeline, root cause (where identified), and corrective actions taken to reduce recurrence.
• Post-quantum cryptography secure: No

Secure development

• Approach to secure software development best practice: Supplier-defined process

Public sector networks

• Connection to public sector networks: No

Pricing

• Discount for educational organisations: No
• Free trial available: No

Discount percentage by annual call-off contract value (excluding VAT)

• Less than £250,000: 0%
• Between £250,000 and £500,000: 2%
• Between £500,001 and £1,000,000: 3%
• Between £1,000,001 and £2,500,000: 3.5%
• Between £2,500,001 and £5,000,000: 3.5%
• Over £5,000,001: 4%

Non-mandatory Standards and certifications

• ISO/IEC 27001 certification: No
• ISO 28000:2022 certification: No
• ISO 9001 certification: No
• Quality management systems (QMS): No
• CSA STAR certification: No
• PCI certification: No
• Cyber essentials: Yes
• Please provide your Cyber Essentials Certificate Number: 66cafce3-c021-4c3f-a24d-2849d622a7c7
• Cyber essentials plus: No
• Cyber Essentials Alternative: None of the criteria
• Other security certifications: No

Social value

• Section B - Commitment for Future: Delivery:

  • Mission: Kick start economic growth. To secure the highest sustained growth in the G7 - with good jobs and productivity growth in every part of the country making everyone, not just a few, better off.

    Policy Outcome 3: Resilient, innovative and flexible supply chains: Support economic growth through enabling resilient businesses, opportunities for small businesses and voluntary, community and social enterprises

    • Understanding of local demographics, needs and opportunities for the co-design of the goods, services and works to be delivered under the contract
    • Measures to involve local stakeholders and/or users in design (e.g. in the design of services, systems, products or buildings)
    • Plans for positive actions with community groups.
    • Measures to engage users and communities and build relationships to increase community integration build trust and influence how the contract is delivered

Service documents

• Pricing document

  ODT

• Service definition document

  ODT

• Terms and conditions

  ODT

Request an accessible format

If you use assistive technology (such as a screen reader) and need versions of these documents in a more accessible format, email the supplier at alex.clark@railbat.uk. Tell them what format you need. It will help if you say what assistive technology you use.