Bug Reports

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

612 Responses to “Bug Reports”

  1. Admin says:

    Hi Lenny,
    Thanks for the correction – now amended.

  2. Admin says:

    Hi Berdy,
    I’m reluctant to duplicate the timing data because the lap times are the largest element of the database. However, if more users request it I’ll consider it.

  3. Admin says:

    Many thanks Michal – now updated.

  4. Roman says:

    In the last GP (France GP) results table, you forgot about Grojean. And as a result, the table has only 19 rows instead of 20. Could you pleas? fix it.


  5. Admin says:

    Hi Roman,
    Thanks for the warning – now updated.

  6. Pete says:

    Hi! Is there a way to tell from the API what grid position a driver starts the race in? For example, in Monaco this year, Gasly qualified 5th but started the race in 8th due to a penalty. This is a problem for the code I am writing to apply the Fantasy F1 rules and tell how many grid places a driver gained/lost during the race

  7. Pete says:

    I swear to God I looked for hours, and just saw ‘grid’ in the results. Sorry!

  8. Admin says:

    Hi Pete,
    I’ve added a note on the qualifying page as the location is not obvious.

  9. Michel says:


    First a big thanks for the providing the API.

    I found that the results for year 2011 round 3 is not containing the fastest lap data. It’s the first race results I found not containing this data. Is this a bug or isn’t this data available?


  10. Admin says:

    Hi Michel,
    Thanks for the warning – I’m not sure what happened there!
    Now corrected.

  11. Stergios says:


    In the latest race results (Belgium GP 2019), the ‘positionText’ field for Norris is “112” instead of “11”.

  12. Michel says:

    Thanks Chris!

  13. sankex says:

    Hi Admin,

    Norris’ results for the 2019 Belgian GP has a typo in their position text (112 instead of 11, see below for example)


  14. Admin says:

    Thanks sankex – now corrected.

  15. thomas says:

    Roster changes for Albon/Gasly are not taken into account.
    Thanks for the amazing API!

  16. Admin says:

    Hi Thomas,
    Can you be more specific – what needs to change?

  17. Coen says:


    For the 2015 Chinese GP it shows in your data that Max Verstappen finished in 17th position. But on the official F1 website it says he DNF’d.

    raceId = 928
    driverId = 830
    F1.com link: https://www.formula1.com/en/results.html/2015/races/919/china/race-result.html


  18. mkl says:

    @Coen – he completed 90% of winner’s number of laps, he was classified.

  19. Thiago says:

    Hello guys,

    I was working with pit stops times and I noticed there are 112 records where the duration seems quite odd (for instance here: http://ergast.com/api/f1/2016/1/pitstops?limit=45). Checking on https://www.formula1.com/en/results.html/2016/races/938/australia/pit-stop-summary.html, I see the same.

    Is the data wrong or I’m missing something?

  20. mkl says:

    It was the red flag period when all the cars returned to pit lane.

  21. Mike says:

    Hi –

    Missing fastest lap result for Mexico GP..

    Keep up the great work on the api 🙂



  22. Admin says:

    Hi Mike,
    They were added early on Monday – I was asleep before they came out on Sunday!

  23. Harry says:


    “Lotus” and “Lotus F1” are missing Constructor Table information.
    They are both recognised as constructors but when accessing it to find it’s nationality they both show blank for name, nationality and it’s Information Field.

    No desperation to get it fixed on my end. Just thought you would like to know xD.

    Thanks, Harry

  24. Luke says:


    I was wondering if there was an exact time every week that the latest race results were updated? Or even if it’s just a rough estimate – would you be able to provide me with that? I want to cache the API responses, but would like to clear this cache at least once a week, and ideally when I know for certain the latest results have been updated.

    Many thanks,

  25. Luke says:

    Whoops! I’ve just read your FAQ. Apologies.

  26. Michel says:

    I found an error in the qualifying results for the 2019 Russian GP. Kyvat is listed as a driver for Red Bull.

  27. Admin says:

    Thanks Michel – now corrected

  28. Brad says:

    Hi Chris,

    I believe RIC and HUL were both disqualified in the Japanese Grand Prix; however, the Results still show them finishing +1 Lap.


  29. Admin says:

    Hi Brad,
    Thanks for the heads-up – now corrected.

  30. If I look at the standings of 2020 I see that Stoffel is also mentioned. Is that correct? I thought he partitions in the Formula E


  31. Stergios says:

    Hi Chris,

    I’ve notices that Nicholas Latifi is missing from the driver’s table. Can you please add it?

    Thank you

  32. Admin says:

    Thanks Wesley – now corrected.

  33. Admin says:

    Hi Stergios – he is there: http://ergast.com/api/f1/drivers/latifi

  34. Stergios says:

    Thanks Chris. I was actually trying to find him the ANSI compatible DB dump. Anyways, I work around that.

  35. Vinicius Carvalho says:

    Hi there, I noticed that the ANSI and Postgres version of the database are still not compatible with postgres SQL. It still uses things like AUTO_INCREMENT. Any chance you could provide a postgresql version of the database?

    Thank you

  36. Michel Post says:

    Thanks for the great work!

    When will the 2020 drivers and constructors be available?


  37. Admin says:

    Hi Vinicious,
    I’m not sure how to improve the approach for creating the PostgreSQL dump which is currently:

    mysqldump –default-character-set=utf8 –compatible=postgres f1db -r f1db_postgres.sql

    If all else fails perhaps you could try loading the CSV tables?
    Best regards,

  38. Admin says:

    Hi Michel,
    The driver and constructor queries will only return the 2020 data after the first race, due to the structure of the API. However, you can get listings using:

  39. Admin says:

    Hi Stergios,
    I’ve updated the database dumps, if that’s any help.

  40. Daniel says:

    Hi Chris,
    it would be great to have the database dump in a sqlite compatible version, and the ANSI version does not really help at this point because of compatiiblity issues.

    As you are using MySQL as your primary DB, you could easily run the script offered at https://github.com/dumblob/mysql2sqlite to have a proper sqlite dump. It’s a one-liner.
    I don’t know how the others feel, but I think this one would help more than the ANSI-version for many use cases.

    Keep up the great work
    Daniel (GP Companion)

  41. Admin says:

    Hi Daniel,
    I’m very happy to produce regular MySQL or CSV dumps using any options that people require – however, I don’t want to take responsibility for converting to other database formats, or the ongoing monitoring and testing that this would require. I want to focus my limited time on the data and the API.

  42. mkl says:

    I’ve played around with mysql2sqlite on the dumps, but without success, as that tool requires specific MySQL dump format. So the conversion on user’s/dev’s side would require loading the dump to MySQL, exporting it in a proper format and hoping that it’s enough for mysql2sqlite.

    I did, however, finally find some time to write a script that converts this specific MySQL dump into an SQLite3-compatible version, by simply doing a bunch of grep and sed operations.
    It of course strips MySQL features like auto increment and default table charsets (and, unfortunately, non-primary and non-unique key indices, defined as “KEY n” in the original dump), but other than that, looks like loading the resulting dump into SQLite3 succeeds – and the provision that it does not aspire to be a universal conversion script (especially if the upstream dump format changes) should go without saying 🙂

    The script’s part of my personal ergast-related toolset: https://github.com/emkael/ergast-goodies

  43. Toby Masters says:

    Hey Chris
    Hope you’re well. Just tried grabbing the latest db image ahead of first 2020 GP this weekend. Looks like last update was 20 March. The API seems to be showing the correct updated 2020 schedule but image needs updating. Same for the CSV dump.

  44. Admin says:

    Hi Toby,
    Apologies – not sure what happened there. Now updated.

  45. Rafa? says:

    Hello, i think that i found small bug in table qualifying:
    Probably this q1 time should be “1:43.693”

  46. Admin says:

    Hi Rafa,
    Thanks for the correction – now updated

  47. john says:

    Hello, is this endpoint response ok? “http://ergast.com/api/f1/2015/driverStandings”
    It’s returning only the results until the third race and yesterday returned all season information.

    PD: Great API! Great job!

  48. Admin says:

    Hi John,
    Thanks for the warning – I unwittingly introduced a bug whilst fixing something unrelated. It should be ok now.

  49. atom6 says:

    Would it be possible to include an actual sqlite database dump as well ? The ansi format is not compatible with sqlite3, there is a script available on github “mysql2sqlite” that works. https://github.com/dumblob/mysql2sqlite

Add a Comment: