RailBat

Rail clash alert tool

Rail Clash Alert Tool is a browser-based application that lists live rail services and highlights predicted clashes at configured junctions. It uses historic movements and AI-enabled ensemble forecasting to estimate lateness at remaining calling points and surface conflict risks in real time. Access is via secure web login.

Features

• Live view of services on configured network
• Predicted clashes at key junctions and constraints
• AI-enabled ensemble lateness forecasts at remaining calling points
• Configurable junctions, thresholds, and alert rules
• Web dashboard with filtering, drill-down, and export

Benefits

• Earlier identification of conflicts and knock-on disruption
• Faster operational decision-making and mitigation planning
• Better situational awareness across control and planning teams
• Better situational awareness across control and planning teams

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

610777485699640

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: Control room tools, operational dashboards, and planning systems can use the service to detect predicted junction conflicts and prioritise mitigations using live and forecast performance signals.
• Cloud deployment model: Private cloud
• Service constraints: The service is delivered as a web application and does not control railway operations. Clash alerts and forecasts are indicative and provided for decision-support purposes only. Buyers can configure monitored junctions, thresholds, and alert rules but cannot modify the underlying forecasting logic. Planned maintenance may result in temporary unavailability, with advance notice where possible.
• System requirements:
  • Modern web browser (Chrome/Edge/Firefox).
  • Reliable internet access to the service.
  • Supported SSO/MFA (if required).
  • Ability to manage users and roles.
  • Network allowlisting for service URLs (if needed).
  • Export capability for reports (CSV/JSON/PDF if offered).

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 secure login credentials and guidance on accessing the service, navigating the interface, and viewing live services, alerts, and reports. We provide online user documentation covering core features, configuration options, and common workflows. Basic troubleshooting information is included to help users resolve typical issues (for example access or configuration problems). 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, user access is removed and accounts are disabled. Buyers are not permitted to retain or continue using service outputs (including alerts, forecasts, or reports) after contract end unless explicitly agreed in writing.
• End-of-contract process: At the end of the contract term, access to the service is terminated and user accounts disabled / access removed, meaning users can no longer access the service. Offboarding guidance explains how to stop app 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 to support different ways of consuming the information. Offboarding guidance includes how to stop 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: Yes
• Supported browsers:
  • Microsoft Edge
  • Firefox
  • Chrome
• 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 accessed through a secure web interface. Authorised users sign in and view live services, predicted lateness, and clash alerts at configured junctions. Users can filter by route, junction, time window, and severity, and review supporting context for each alert. Administrative users can manage user access and configuration settings.
• Accessibility standards: None or don’t know
• Description of accessibility: The service is delivered through a web interface and is designed to be usable with keyboard navigation and common assistive technologies. Users can view and filter alerts, navigate between pages and tables, and access supporting details without relying solely on colour. Responsibility for the buyer’s overall accessibility compliance (including any embedding or downstream use) rests with the buyer.
• Accessibility testing: We have not completed formal testing with users of assistive technology. We have reviewed the web interface and supporting documentation against accessibility best practice, including keyboard-only navigation, focus visibility, readable layouts, and clear labelling of controls. We aim to avoid colour-only status indicators and provide text labels for alert severity and state. If buyers require specific accessibility assurance (for example WCAG-aligned testing evidence), we can discuss reasonable adjustments and a testing plan as part of onboarding or implementation.
• API: No
• Customisation available: Yes
• Description of customisation: Customisation is limited to configuration within the service, such as monitored junctions, thresholds, alert rules, user roles, and views. Buyers cannot customise the underlying forecasting models or core service behaviour. Non-standard integrations, bespoke alert logic, or additional data sources may incur additional cost by agreement.

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 usage 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 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 through export functionality on the tool and saving 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 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 software

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 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.