TfL Transport Alerts Scraper

🚇 TfL Transport Alerts Scraper is a powerful Apify Actor designed to discover, track, and collect real-time London transport status and disruption data directly from Transport for London's own public API. This tool provides comprehensive TfL Transport Alerts intelligence including transport mode, line name, status severity, delay reason, and affected stations for any keyword across tube, bus, overground, DLR, and tram services. Whether you're building a commuter alert dashboard, tracking service disruptions, or conducting transport research, the TfL Transport Alerts Scraper delivers actionable TfL Transport Alerts insights efficiently.

With dual-endpoint status and disruption querying, keyword-based full-text filtering, station extraction, and reliable Apify Dataset delivery, the TfL Transport Alerts Scraper ensures comprehensive TfL Transport Alerts coverage across every major mode of London transport. It focuses on key TfL Transport Alerts signals including status severity, delay reason, and affected stations, making it an essential tool for commuter alerting and transport monitoring.

---

📋 Table of Contents

• Features
• Data Source
• How It Works
• Input
• Output
• Technical Stack
• Data Fields
• Use Cases
• Quick Start
• Configuration
• Performance
• Important Notes
• License & Legal

---

🔥 Features

• Direct TfL API Access – Queries Transport for London's official public API (api.tfl.gov.uk) directly for fast, structured TfL Transport Alerts data.
• Dual-Endpoint Coverage – Queries both the Status endpoint and the Disruption endpoint to maximize alert coverage.
• All Major Transport Modes – Covers tube, bus, overground, DLR, and tram in a single run.
• Keyword Full-Text Search – Matches any keyword against the combined line name, transport mode, delay reason, and status description.
• Affected Station Extraction – Parses parenthetical station names out of delay reason text automatically.
• Cross-Endpoint Deduplication – Tracks a unique alert ID per line/reason pair to avoid duplicate entries between the two source endpoints.
• Residential Proxy Support – Optional Apify proxy with configurable groups and country targeting.
• Pay-Per-Event Charging – Integrates with Apify's pay-per-event model, charging only for unique, successfully saved alerts.
• Local Run Detection – Automatically skips charging during local/test runs outside the Apify platform.
• Charge Limit Awareness – Stops processing automatically once the run's configured maximum charge limit is reached.
• Real-Time Dataset Push – Pushes each unique TfL Transport Alerts record to Apify Dataset as it's found.

---

📊 Data Source

Transport for London (TfL) Unified API

• Authority: Transport for London's official public API (api.tfl.gov.uk)
• Access Method: Direct HTTP GET requests via requests, querying the Line/Mode/.../Status and Line/Mode/.../Disruption endpoints
• Coverage: Any current status entry or disruption across tube, bus, overground, DLR, and tram services
• Data: Structured JSON line status and disruption records
• Access: Public API, no API key required for these endpoints
• Update Frequency: Reflects TfL's live service status at time of run

---

⚙️ How It Works

The TfL Transport Alerts Scraper queries two TfL API endpoints — one for general line status across all major modes, and one specifically for disruptions — to maximize alert coverage. For each returned item, it extracts the line or system name, transport mode, and every associated status/disruption entry, building a combined search string from the line name, mode, delay reason, and status description. If no keyword is provided, or if the keyword matches this combined text, the alert is included. Affected station names are parsed out of the delay reason text using parenthetical pattern matching. A unique alert ID (based on line name and the start of the reason text) prevents the same alert from being saved twice, even when it appears in both source endpoints. Each unique alert is pushed to the Apify Dataset immediately; if running on the Apify platform (not a local/test run), the Actor also charges a pay-per-event fee for each unique alert saved, stopping automatically if the run's charge limit is reached.

Key Processing Steps:

1. Input Parsing – Accept an optional keyword and proxy configuration
2. Proxy Setup – Configure Apify proxy with optional group and country targeting
3. Endpoint Loop – Query the Status endpoint, then the Disruption endpoint
4. Item Parsing – Extract line name, transport mode, and status/disruption entries from each item
5. Keyword Matching – Include the alert only if the keyword matches the combined search text (or no keyword was given)
6. Deduplication Check – Skip any alert whose unique ID has already been seen across either endpoint
7. Station Extraction – Parse affected station names from parenthetical text in the delay reason
8. Dataset Push – Push each unique alert record to the Dataset immediately
9. Pay-Per-Event Charging – Charge for each unique alert saved, when running on the Apify platform
10. Limit Enforcement – Stop processing further alerts once the configured charge limit is reached

Key Benefits:

• Pull TfL Transport Alerts data for any keyword without manually checking the TfL website
• Cover every major London transport mode in a single run
• Automatically extract affected station names from disruption text
• Feed commuter alert dashboards, transport research pipelines, or notification tools
• Automate recurring TfL Transport Alerts checks as service status changes throughout the day

---

📥 Input

The Actor accepts the following input parameters:

Field	Type	Default	Description
keyword	string	""	Optional keyword to filter alerts by line, mode, reason, or status text. Empty returns all alerts.
proxyConfiguration	object	(none)	Optional Apify proxy configuration, with proxyGroups and apifyProxyCountry sub-fields.

Example Input:

{
  "keyword": "central line",
  "proxyConfiguration": {
    "proxyGroups": ["RESIDENTIAL"],
    "apifyProxyCountry": "GB"
  }
}

Fetch All Current Alerts:

{
  "keyword": ""
}

Filter by Transport Mode:

{
  "keyword": "bus"
}

---

📤 Output

The Actor pushes TfL Transport Alerts records with the following structure:

Field	Type	Description
transport_type	string	The transport mode (e.g., "tube", "bus", "overground", "dlr", "tram")
line	string	The affected line or system name
status	string	Status severity description (e.g., "Good Service", "Minor Delays", "Disruption")
delay_reason	string	The reason text for the alert or disruption
affected_stations	array	Station names parsed from the delay reason, or ["Not Specified"] if none found
city	string	Always "London"
source	string	Always "TfL API"
timestamp	string	ISO 8601 timestamp of when the alert was scraped

Example TfL Transport Alerts Record:

{
  "transport_type": "tube",
  "line": "Central",
  "status": "Minor Delays",
  "delay_reason": "Minor delays due to an earlier signal failure at Mile End (Mile End) and Stratford (Stratford)",
  "affected_stations": ["Mile End", "Stratford"],
  "city": "London",
  "source": "TfL API",
  "timestamp": "2026-09-02T09:00:00.000000"
}

---

🧰 Technical Stack

• HTTP Client: requests for direct access to the TfL Unified API
• Pattern Matching: re for extracting affected station names from parenthetical delay-reason text
• Async: asyncio for the Actor's run loop
• Proxy: Apify Proxy with configurable groups and country targeting
• Monetization: Apify's pay-per-event charging via Actor.charge()
• Logging: Apify Actor logging system
• Platform: Apify Actor serverless environment

---

📊 Data Fields Explained

Alert Identity

• line: The name of the affected line or system-wide entry
• transport_type: Which mode of transport the alert applies to

Alert Details

• status: The severity/category of the current status or disruption
• delay_reason: The full text explanation for the alert
• affected_stations: Station names extracted from the delay reason text, when present

Metadata

• city / source: Fixed context fields identifying the alert's origin
• timestamp: When this specific alert record was scraped

---

🎯 Use Cases

• Commuter Alerting – Build a personal or team notification system for specific lines or stations
• Transport Research – Study disruption frequency and causes across London's transport network
• Service Reliability Monitoring – Track how often specific lines experience delays or disruptions
• Journalism – Source primary disruption data for local transport news coverage
• App Integration – Feed real-time alert data into a commuter-facing app or dashboard
• Academic Research – Study public transport disruption patterns at scale

---

🚀 Quick Start

1. Prepare Input

Go to Apify Console and enter:

{
  "keyword": ""
}

2. Run the Actor

Click Start. The Actor will:

• Query TfL's Status and Disruption endpoints across all major transport modes
• Filter results by keyword, if provided
• Deduplicate alerts across both endpoints
• Push each unique alert to the Dataset

3. Monitor Progress

Console shows:

Scanning TfL for maximum results... Keyword: 'central line'
[CHARGED] Alert: Central (Minor Delays) | Event: 'scraped-result' | Total charged so far: 1
Done! Found 3 unique alerts.
Total charged this run: 3

4. View & Download Results

• Results Tab: All TfL Transport Alerts records
• Export: JSON, CSV, Excel, or HTML
• Filter: By transport type or status
• API Access: Available via the Apify API

---

⚙️ Configuration

All current alerts, no keyword:

{
  "keyword": ""
}

Filter by a specific line:

{
  "keyword": "jubilee line"
}

Filter by transport mode:

{
  "keyword": "overground"
}

---

📈 Performance

Processing Speed

• Two API requests per run (Status endpoint + Disruption endpoint), regardless of keyword
• No pagination or pacing delay needed, since both endpoints return complete current-state data in one call
• Very fast overall, since no browser rendering is involved

Resource Usage

• Memory: Low, since only two lightweight JSON requests are made
• Network: Two requests per run
• Proxy: One proxy connection shared across both requests, if configured

---

⚠️ Important Notes

Monetization Notice

• This Actor uses Apify's pay-per-event pricing model: each unique alert saved to the Dataset (on the Apify platform, not local/test runs) triggers a charge under the "scraped-result" event
• If a per-run charge limit (ACTOR_MAX_TOTAL_CHARGE_USD) is configured, the Actor stops processing further alerts once that limit is reached, so later alerts in the same run may not be captured
• Running the Actor locally or outside the Apify platform skips charging entirely — useful for testing without incurring costs

Legal & Compliance

• Fair Use: Uses TfL's official public API as intended, with no authentication required
• Public Data Only: Retrieves only publicly published TfL Transport Alerts data
• Legal: Not legal advice — consult qualified professionals before using this data for compliance-sensitive decisions

Data Quality

• Freshness: Reflects TfL's live service status at time of run — status can change within minutes
• Completeness: affected_stations returns ["Not Specified"] when no parenthetical station names are found in the delay reason text
• Accuracy: Sourced directly from TfL's own Unified API
• Verification: Cross-check high-stakes commuting decisions against the live TfL website or app before traveling

Best Practices

• Leave keyword empty to capture the full current alert picture across all modes
• Re-run frequently (e.g., every few minutes) for near-real-time commuter alerting, keeping the pay-per-event cost model in mind
• Be aware that the charge limit may cause a run to stop before capturing every alert during a high-disruption period
• Use specific line or station names as keywords to build targeted, personal alert feeds

---

📄 License & Legal

Terms of Use:

• Use for legitimate research, commuter alerting, and transport monitoring purposes
• Respect TfL's API Terms of Use
• Use TfL Transport Alerts data responsibly and in compliance with applicable laws
• Not a substitute for checking official TfL channels before travel

Disclaimer: TfL Transport Alerts Scraper is provided as-is for research and monitoring purposes. Users are responsible for compliance with TfL's terms and all applicable laws. This is not legal advice. Always verify critical travel information against official TfL sources.

---

⚖️ TfL Transport Alerts Excellence

This Actor is optimized for TfL Transport Alerts research with:

• ✅ Direct, official TfL API access — no HTML scraping fragility
• ✅ Dual-endpoint coverage for maximum alert detection
• ✅ Automatic station extraction from disruption text
• ✅ Cross-endpoint deduplication
• ✅ Pay-per-event monetization support
• ✅ Real-time Dataset push
• ✅ Production-ready code