Bug Reports

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


796 responses to “Bug Reports”

  1. lingfish Avatar

    Agree with sperry, round numbering is wrong due to Italy cancellation.

  2. Admin Avatar

    Sperry, Lingfish – does the FIA use round numbers? I can’t see any in use on the FIA site.

  3. Novik Avatar

    Hi, it looks like timing data for Hamilton and Russsell are incorrect for Monaco GP 2023. Likely similar to previous reports for other GPs this year.

    Thank you for maintaining this resource! 🙂

  4. sperry Avatar

    Based on the schedule on the F1 website itself, it lists each round with a round number (https://www.formula1.com/en/racing/2023.html). They still have Italy listed as round 6 but flagged as “Called Off”.

    But you’re right, they don’t list round numbers on their results page (https://www.formula1.com/en/results.html/2023/races.html).

    I can’t really think of a precedent about whether or not the the round numbers should be kept or reused for cancelled rounds. The only previous cancelled round I can think of, that’s at all recent, is back in 2011 when Round 1 in Bahrain was called off during the Arab Spring. In that instance, they just renumbered the rest of the season starting with round 1 in Australia. But since that was effectively before the season started, it was more like a preseason adjustment to the schedule than a cancelled round.

  5. Patryk Avatar


    No option to create a query

  6. Koushik Avatar

    I came across 2 issues when using the API

    1. The API does not return the primary key (id) as a part of the response. Is there a reason for why it is so? I am writing a program to update the local tables before running the code/analysis each time, and not returning the primary key is kind of stopping me from doing that. I also noticed that certain other columns are not returned. For example – when querying the circuit information using http://ergast.com/api/f1/circuits, the response doesn’t include the `alt` column. I just want API endpoints that I can query plainly without any specific filters and get the whole underlying table as is. Is there a workaround? Has anyone already achieved it in python where I can update all my local database tables with the latest data?

    2. The `sprintResults` SQL table has the primary key `sprintResultId` and the csv export has the column renamed as `resultId` in the `sprint_results.csv` file. This is causing an unnecessary corner case while parsing the csv files and dumping them into SQL tables.

  7. Uty E. Avatar
    Uty E.

    thanks for maintaining this!

  8. Admin Avatar

    Thanks Novik – now corrected.

  9. Admin Avatar

    Hi Patryk – thanks. The recent, forced update to WordPress seems to have broken it – I’ll investigate.

  10. Admin Avatar

    Hi Koushik,
    THe internal (integer) database IDs shouldn’t be used externally because they’re not stable. The string identifiers for drivers, constructors, etc provided in the responses are stable so use these as keys.

    The alt column is missing if it’s empty – I’ll try to add the missing values.

    The sprintResultId may be a mistake – I’ll investigate.


  11. Admin Avatar

    Hi Sperry,
    I’m not keen on including round numbers for non-existent races as it causes a number of problems – certain API calls (like current/last/results) will return empty tables etc. The FIA (rather than formula1.com) doesn’t appear to use them.

  12. Koushik Avatar

    Thank you for the quick response @admin

    I had one more query. Is it possible to include a new column in the lapTimes table to store the type of tire the driver was using during that lap? I don’t know how exactly the data here is curated, so I’m not sure if this is possible. But it would be extremely useful if we had one such column.

    If the tire data is, in fact, publicly available and you need some help in scraping/automating the data pull, I’m happy to help 🙂

  13. Joey Avatar

    Hi, first i wanna say thanks for maintaining this API it is amazing.
    The issue i am encountering is that the sprint shootout date is put under practice 2 and is +30 minutes off

    – Joey

  14. sperry Avatar

    Thanks for the update Chris!

    I’m happy either way, I just wanted to know if there was a decision on how to handle cancelled rounds. If the round indexes are purely ordered indexes and not intended to match the Formula 1 schedule’s round numbering, that’s perfectly reasonable and consistent!

    Appreciate all the effort in maintaining this database and API!

  15. Martinspire Avatar

    Very nice API to use. Been fiddling around with it and really like how detailed everything is.

    Any idea when Sprint Quali is added to the races and results? Since that is now a separate session

  16. FraM Avatar

    Hi! I noticed a few races in which the qualifying result is missing, but the race result is there, I’m not sure if I made some mistake while downloading the data, am I the only one with this problem?

    In particular the following raceId are present in the results and races datasets, but not in the qualifying one:
    124 126 127 128 129 130 131 132 133 134 135 136 137 138 139 141 142 143 144 145 146 147 148 149 150
    151 152 153 154 155 157 159 162 163 164 165 166 167 168 169 170 171 172 174 178 179 180 181 182 183
    184 185 186 187 188 189 190 194 195 196 197 198 202 204 205 206 217 218 219 220 221 222 223 231 232
    233 234 235 236 237 238 239 260

  17. Admin Avatar

    Hi Koushik,
    I haven’t found a reliable and consistent source of tyre usage data. Which source are you looking at?

  18. Admin Avatar

    Hi Joey,
    Which race are you looking at? Can you explain what you mean by “put under practice 2”.

  19. Admin Avatar

    Hi Martinspire,
    There’s a note at the end of the FAQ

  20. Admin Avatar

    Hi FraM,
    There’s a note in the documentation page. I have more historical data now but haven’t had time to load it.

  21. Aniket Ghodinde Avatar
    Aniket Ghodinde

    For Driver Standing Api if pagination limit is set above 200 then response is truncated.
    Try In postman

  22. Joey Avatar

    Hi Chris,

    The previous raceweekend (Austria) had a Sprint Shootout instead of practice 2 and the time listed (on practice 2) was 30 minutes later then the shootout was.

  23. Fernando Avatar

    How can I help to develop this website?



    In 2001 in the laps by laps (laptimes), the performances of Alesi and Trulli were reversed during the period when they were teammates at Jordan

  25. Brandon Avatar

    For Hungary 2023 your data has Logan Sargeant finishing +3 Laps, however, they retired the car and the FIA lists him as a DNF.



  26. Admin Avatar

    Thanks Brandon – now corrected.

  27. Ramon Avatar

    For the 2011 Singapore GP (round 14), I think Vettel’s race time, listed as “1:59:04.757”, is incorrect. It’s inconsistent with the millisecond count “7146757” – off by 2000ms. From all the sources I could find (see below), I think the time should be “1:49:06.757”, which would fix the 2s inconsistency.


    Thanks for the awesome work!

  28. Brandon Avatar

    Hi Chris

    The FastestLap data is missing from the JSON response for Round 12?http://ergast.com/api/f1/2023/12/results.json


  29. Admin Avatar

    Hi Aniket,
    I couldn’t produce this error. However, this query is likely to be very slow because you’re asking for a very large amount of data. That could cause a timeout or a memory error. Please use several smaller queries by adding a year parameter. It’s likely to be faster.

  30. Admin Avatar

    Hi Fernando,
    The database admin system is very creaky and needs to be re-written – this time as a multi-user collaborative system and perhaps using Django? Would that be something you would be interested in helping with?

  31. Admin Avatar

    Hi Antoine,
    That’s not going to be easy to fix. Do you have the original data?

  32. Admin Avatar

    Thanks Ramon,
    Now corrected.

  33. Admin Avatar

    Hi Brandon,
    It’s there now. The FIA was late publishing the data.

  34. Ramon Avatar


    I’m working on some stuff that’s parsing the API responses and I think I’ve found a few errors:

    1954, round 5, P2:
    ‘Time.millis’ is an empty string. Should it be “10644000”, calculated from “+1:10”?

    1961, round 4, P28:
    ‘Result.number’ field is an empty string. I think it should be “28” (same as .position, just a coincidence: https://en.wikipedia.org/wiki/1961_French_Grand_Prix)

    1994, round 9, P3:
    “1:05.0421” is invalid, I think it should be “1:05.421”

    2011, round 10, P1:
    “1:37:30.344” does not match millis “5850334”, I think it should be “1:37:30.334”

    2011, round 14, P1:
    “1:49:06.757” does not match millis “7146757”, I think it should be “1:59:06.757”

    For the following, the ‘Result.number’ field is an empty string. I couldn’t find a car number for these, I don’t think they had one. I guess an empty string is as good a solution as any, in this case, to mean no-number, but bringing these to your attention just in case. Might also consider “0” to mean no-number, similarly to how it means a pit lane start on .grid.

    1962, round 4, P19-22: ‘Result.number’ field is an empty string.
    1963, round 10, P23: ‘Result.number` field is an empty string.

    Sorry to dump these on you. I’m not sure if there is a way to make contributions to the DB directly?

    Thanks for the great work!

  35. Admin Avatar

    Thanks Ramon,
    I’ll try to correct these.

  36. Guillermo Avatar

    Hello Chris! I have noticed that Paul di Resta does not have a permanent number in the database, despite having participated in the 2017 Hungarian Grand Prix. It seems he drove under the number 40. I think this is a bug, unless I am missing something?

    Thanks for all the hard work! 🙂

  37. Admin Avatar

    Hi Guillermo,
    Thanks for the warning – now corrected.

  38. Christian Rokitta Avatar

    There is a data error in the PitStop data for race season 2023, round 13.
    The data for L. Hamilton has a wrong duration value:

    “driverId”: “hamilton”,
    “lap”: “64”,
    “stop”: “5”,
    “time”: “16:33:59”,
    “duration”: “40:31.108”

  39. Admin Avatar

    Hi Christian,
    What’s your reference? The API appears to agree with the FIA records.

  40. Philipp Avatar

    Hi Chris, it looks like your SSL Certificate has expired today, causing connection errors.

  41. Adam Avatar

    Hey, I’m trying to fetch some data and it worked previously (~1-2month ago), but now I get the following error:
    https://ergast.com/api/f1/2023/drivers.json net::ERR_CERT_DATE_INVALID

    Could you help me out with this one?

  42. Marco Kreeft Avatar
    Marco Kreeft

    Hey Adam, I’ve got the same issue. This isnt anything we can fix. Chris is the only one who can fix this

  43. Admin Avatar

    Philipp, Adam, Marco,
    Apologies – the auto-renew failed on the new server. It should be ok now.

  44. Christian Avatar

    It seems to me that there is an error in the fastest lap in the 2020 Bahrain GP

  45. Pablo Avatar

    Hi. As you know, the official name for the Brazilian GP since 2021 is São Paulo Grand Prix. However, this name appears in 2021 and 2023 season, but it’s not updated in 2022 season.

  46. Admin Avatar

    Hi Christian,
    Can you be more specific?

  47. Admin Avatar

    Hi Pablo,
    Amended as suggested.

  48. Xuanyi Wang Avatar
    Xuanyi Wang

    Hi! I found a (potential) inconsistency in the data. resultId = 19302 (Mike Hawthorn in 1954 British GP) has a missing `milliseconds` but non-missing `time`. If I understand it correctly, we should always be able to calculate milliseconds based on the race time of the winner plus the gap to the leader. So either both of them are missing, or both are non-missing. See https://github.com/theOehrly/Fast-F1/discussions/446

  49. Belmiro Avatar

    Looks like that the times for the Qatar race are not right. Can you check it, please?

    For example, the race would be 17:00:00Z, not 14:00:00Z.

  50. Codie Westphall Avatar
    Codie Westphall

    Hey there. As pointed out by the above commenter, you have a bug with translating Arabic Standard Time, your library conversion is confusing AST to mean Atlantic Standard time when the correct time zone should be Arabic Standard Time. This can often be the case when you create timezones with the abbreviation. Using an identifier such as “Asia/Qatar” will produce the correct UTC+3 time information

Leave a Reply

Your email address will not be published. Required fields are marked *