FastF1: Formula 1 timing, telemetry and results in Pandas

What FastF1 solves, and for whom

Formula 1 publishes a lot of timing and telemetry, but it does not publish it in a shape that is convenient for analysis. FastF1 exists to close that gap for people working in Python. The README describes it as a package for "accessing and analyzing Formula 1 results, schedules, timing data and telemetry", and the main feature list is explicit about the target audience: developers who are comfortable with Pandas and Matplotlib.

The design decision that matters most is that data arrives as extended Pandas DataFrames rather than as plain dictionaries or custom objects. FastF1 adds methods to those objects specifically for F1 work, so a lap time table can be filtered, joined and plotted with the same idioms you already use for any other tabular data. If you have never used Pandas, this package will not teach you; it assumes the toolchain.

The secondary audience is anyone who needs historical coverage. The README states full support for the Ergast compatible jolpica-f1 API to access current and historical F1 data, which means the same code path serves a race from this season and a race from years ago. That is a different proposition from scraping a live timing page, and it is the reason the package is useful for long-running analysis rather than one-off lookups.

How FastF1 gets data into a DataFrame

The architecture is a thin, opinionated layer over two kinds of source: an HTTP API for schedules, results and session metadata, and a timing feed for the finer-grained data. The README names jolpica-f1 as the API it supports for current and historical data, and lists caching for all API requests as a feature, which tells you the package expects to be called repeatedly rather than once.

Caching is the load-bearing part of the design. A script that loads several sessions will otherwise re-fetch the same JSON on every run, and F1 data does not change once a session is over. FastF1 puts a cache in front of those requests so the second run is local. The cache is not incidental: requests-cache appears in the dependency list in pyproject.toml, alongside requests, pandas, numpy and matplotlib.

The dependency list also hints at the second data path. cryptography, pyjwt, signalrcore and websockets are all listed, which is consistent with a live timing connection that authenticates and streams over a socket rather than polling a REST endpoint. The README does not document the live timing protocol in detail, so treat that path as something to read up on in the documentation at docs.fastf1.dev before you build on it.

After loading, the objects are Pandas DataFrames with extra methods attached. That is the whole point of the abstraction: the package does the network and parsing work, and hands you something you already know how to manipulate.

Installing FastF1 and loading a first session

The README recommends pip as the primary install path. The package requires Python 3.10 or newer according to pyproject.toml, so check your interpreter before you start.

pip install fastf1

A conda-forge build is also documented as an alternative, which is useful if you already manage your environment that way.

conda install -c conda-forge fastf1

The README notes that a wheel or source distribution can be downloaded from PyPI if you prefer not to use a package manager. It also mentions Pyodide and other WASM-based environments, but is careful about it: compatibility is described as mostly present and not extensively tested, with additional setup steps documented in an external repository. If you are targeting a browser notebook, read that guide first rather than assuming the pip command is enough.

Once installed, the first real use is to pick a session and load it. The documentation at docs.fastf1.dev is where the session-loading API is specified, and the repository ships a set of example scripts under examples/ organised by topic: general, lap_times, results_strategy, standings and telemetry. Those directories are the fastest way to see the intended call pattern for each kind of data. Start with an example that matches what you want, change the event and session identifiers, and run it.

Where FastF1 is the wrong tool

FastF1 is a client library, not a data platform. It does not host anything, and it does not promise that a given session will remain retrievable. Everything it returns depends on the upstream API and timing feed being reachable and behaving. If your application needs a documented data contract with an availability guarantee, this package is a dependency you cannot control, and you should plan to persist the DataFrames you care about rather than re-fetching them on demand.

The cache helps here, but it is also a source of confusion. The README lists caching as a feature without spelling out where the cache lives or how to invalidate it in the text available. If a script returns something that looks stale, the cache is the first thing to check, and the documentation is where you will find the configuration. Treat cache behaviour as something to verify in your own environment rather than assume.

The live timing path is the other soft spot. The dependency list shows the socket and authentication libraries, but the README does not document the protocol, its reconnection behaviour, or what happens when a session ends mid-stream. Building a long-running collector on an undocumented path is a decision you should make deliberately.

Finally, this is not a visualisation product. Matplotlib integration is listed as a feature, which means FastF1 helps you plot, but you still write the plotting code. If you want a dashboard with no programming, this is not it.

FastF1 compared with the f1dataR R package

The README points to one alternative directly: an R package on CRAN that wraps FastF1, at cran.r-project.org/package=f1dataR. The README is explicit that third-party packages are not directly related to the FastF1 project and that questions about them go to their own maintainers.

The difference in approach is the language and the data model. FastF1 hands you Pandas DataFrames with added F1-specific methods, which means the analysis idioms are Python and Pandas. The R wrapper sits in a different ecosystem, so the same underlying access becomes R data structures and R's own idioms. If your team writes R, the wrapper is the natural entry point. If your team writes Python, using the wrapper adds a language boundary for no benefit.

There is a second alternative worth naming: writing your own requests against the jolpica-f1 API. That is genuinely viable, because the API is documented independently and FastF1 is not the only consumer. What you give up is the parsing, the DataFrame construction, the F1-specific methods and the caching. Whether that trade is worth it depends on how much of the data you actually need; if you want one table of race results, a direct request is less machinery.

Licence, maintenance and upgrade cost

FastF1 is MIT licensed, per the LICENSE file and the classifier in pyproject.toml. That is permissive and places few constraints on how you use the code. It says nothing about the data you retrieve through it, and the README carries a notice that FastF1 and its website are unofficial and not associated with the Formula 1 companies, with F1 and related marks belonging to Formula One Licensing B.V. Redistributing timing or telemetry data is a separate question from the software licence, and the repository does not answer it. That is a question for whoever owns the data, not a legal opinion this article can give.

The project is not archived, and the last push to the main branch was on 2026-08-28. Releases are frequent: v3.8.1 on 2026-02-11, v3.8.2 on 2026-03-29 and v3.8.3 on 2026-04-29. That cadence means you should pin a version in your environment rather than track the branch, because a minor release can change behaviour you depend on.

Upgrade cost is mostly about the dependency floor. pyproject.toml pins pandas to >=2.1.1,<3.0.0, numpy to >=1.26.0,<3.0.0, matplotlib to >=3.8.0,<4.0.0 and scipy to >=1.11.0,<2.0.0, with Python 3.10 as the minimum. If your project is on an older pandas or an older interpreter, FastF1 will force an upgrade of your whole stack. The upper bounds also mean a pandas 3.0 release will require a FastF1 release before you can move.

What to check before you commit

Two things are worth confirming in your own environment before you build on FastF1. The first is the cache: where it writes, how large it grows and how to clear it. The README states that caching exists for all API requests but does not document the location in the text available, so the documentation at docs.fastf1.dev is the place to look.

The second is the live timing path. The presence of websockets, signalrcore, pyjwt and cryptography in the dependency list is consistent with an authenticated streaming connection, but the README does not describe the protocol or its failure modes. If your use case depends on live data rather than historical sessions, prototype that path early, because it is the least documented part of the package.

The examples directory is the cheapest way to answer both questions. It is organised by topic, so a script under examples/telemetry or examples/lap_times will show the calls and the expected object shape without you having to read the API reference end to end.

Editorial conclusion

Adopt FastF1 if your analysis already lives in Python and you want F1 timing and telemetry as DataFrames with a cache in front of the network. Do not adopt it if you need a stable data contract with an SLA, or if you only want a quick chart and no code. Before writing anything long-lived, check the docs for the current cache location and the jolpica-f1 endpoint behaviour, and confirm the licence terms of the data you plan to redistribute.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. theOehrly/Fast-F1 on GitHub