Bug Reports

If you identify any API bugs or errors in the data please record them here.

470 Responses to “Bug Reports”

  1. Admin says:

    Hi Gavin,
    Unfortunately it had to be a quick fix this season. It it does become a regular feature I’ll have to introduce a new table and change the way the standings are calculated. Let’s see what happens.

  2. Admin says:

    Hi Philipp,
    Thanks for the warning – now corrected.

  3. Sergio says:

    Hello, I don’t know if this is a punctual problem but there is an error with the connection to the DB, my app stops working with the error ‘Error: getaddrinfo ENOTFOUND ergast.com’, and I checked other apps that use this API and they have the same problem.

  4. Admin says:

    Hi Sergio,
    This should be fixed now – the name server crashed yesterday and had to be restarted.
    Let me know if you still have problems.

  5. mk says:

    First of all, thanks for your wonderful API.

    I believe I found a bug in fastest lap data for 2021 Hungarian GP. It seems messed up. The ‘results’ table shows that Tsunoda (driverId 852) has the fastest lap of the race with id 1062 with 1:18.394, while in reality this time was set by Gasly. Gasly’s fastest lap in the table is 1:20.359, which, according to all F1 official data I was able to find, belongs to Fernando Alonso. Looks like every single fastest lap in results table for this GP is misattributed.

    Not sure if there’s any other GP with such an error, but hope it’ll eventually get fixed — and thanks again for your work!

  6. Jor says:


    I believe In the 1996 San Marino Grand Prix (at f1/1996/5/qualifying) you are missing the qualifying time of Martin Brundle (12th).

    Also, would you consider adding qualifying rows to the database for drivers who took part but did not set a time? (e.g. Andrea Montermini of the same Grand Prix)


  7. Emre says:


    Turkish Grand Prix date changed. Is it possible for you to update?

  8. Admin says:

    Hi Wesley,
    Thanks for the warning – now corrected.

  9. Admin says:

    Hi Emre,
    Thanks for the warning – now corrected.

  10. Admin says:

    Hi Mk,
    Thanks for the warning – now corrected. There seems to be a bug related to the disqualification edit.

  11. Emre says:

    Thank you for your response. I am using your Docker build. I just recreated the images, but the data in MySQL is out of date. I would be very happy if you update this as well. Thank you.

  12. Admin says:

    Hi Emre,
    The dumps have been updated

  13. Chris says:

    Hello Chris,

    Firstly once again thanks for the amazing API, not sure if you remember me but I built a fantasy formula one system on top of your API for my friends and work colleagues. I meant to say last time I got in touch but if you wanted to enter next year I would be happy to give you an entry to say thanks for the service!

    Just wanted to let you know that the results for – https://ergast.com/api/f1/2021/12/results.json (Belgian GP 2021) the fastest lap doesn’t seem to be defined. I mean perhaps your API couldn’t quite fathom how Nikita Mazepin managed to get the fastest lap, but it seems he did 🙂


  14. Arthur says:


    I noticed that the data for race 3 of 2021 in the CSV download appears to be outdated.
    I get the following:

    1054 | 2021 | 3 | 20 | TBC | 2021-05-02 | | http://en.wikipedia.org/wiki/2021_Formula_One_World_Championship

    The API seems to return the correct information for Portuguese Grand Prix though

  15. Jaco Koster says:

    It seems that the start-time of the Turkish Grandprix 2021 is wrongly stated at 10:10 UTC, which according to the FIA will be the “normal” 13:00 UTC 🙂

  16. Admin says:

    Hi Chris,
    The FIA didn’t publish the fastest lap table for this race. I guess this was because there was only one lap and this was behind the safety car.

  17. Admin says:

    Hi Jaco,
    Thanks for the warning – now corrected.
    Where did you find the info on the FIA site – I still can’t find it!

  18. Admin says:

    Hi Arthur,
    This seems to be correct in the latest download. Unfortunately, there are some bugs in MySQL’s CSV dump method which can cause problems. Deleting rows in the schedule table (due to all the schedule changes) seems to make it worse.

  19. Admin says:

    Hi Jor,
    Thanks for the corrections – both now done.

Add a Comment: