Scheduled maintenance
Twilio Services
Issues related to Twilio’s Software
External Connectivity
Issues found outside of Twilio’s Network
System Metrics
Change in How Super SIM Data Usage is Reported for Some Queries to the UsageRecords API
Incident
Report for Twilio
Resolved
We have determined that we will not be able to revert the unannounced change in API behavior without the underlying usage reporting services becoming degraded, resulting in other queries also failing. We have sent out a detailed email to recent users of the Super SIM UsageRecords API with additional details. We will be updating the UsageRecords API documentation to reflect the new behavior.
We suggest you consider changing all queries to this API for periods greater than 24 hours to use timestamps that fall on UTC hour boundaries to ensure you get accurate and consistent results for your requested start and end times. You may need to rerun reports or adjust amounts persisted to your own systems if you recorded excessive data usage due this unannounced change in API behavior. We apologize for any inconvenience that this causes you
We suggest you consider changing all queries to this API for periods greater than 24 hours to use timestamps that fall on UTC hour boundaries to ensure you get accurate and consistent results for your requested start and end times. You may need to rerun reports or adjust amounts persisted to your own systems if you recorded excessive data usage due this unannounced change in API behavior. We apologize for any inconvenience that this causes you
Update
Our engineering teams are continuing to discuss options for restoring the impacted functionality while maintaining stability in the underlying usage reporting services. We will provide another update on Wednesday, 5/01. In the meantime, it is suggested that if possible, you consider modifying usage queries for periods over 24 hours to use timestamps that fall on UTC hour boundaries to ensure that you get accurate results in case this functionality cannot be restored.
Update
Our engineering teams are continuing to discuss options for restoring the impacted functionality while maintaining stability in the underlying usage reporting services. We will provide another update on Tuesday, 4/30. In the meantime, it is suggested that if possible, you consider modifying usage queries for periods over 24 hours to use timestamps that fall on UTC hour boundaries to ensure that you get accurate results in case this functionality cannot be restored.
Update
Our engineering teams are continuing to discuss options for restoring the impacted functionality while maintaining stability in the underlying usage reporting services. We will provide another update on Monday, 4/29. In the meantime, it is suggested that if possible, you consider modifying usage queries for periods over 24 hours to use timestamps that fall on UTC hour boundaries to ensure that you get accurate results in case this functionality cannot be restored."
Update
Beginning ~18:48 UTC today, when querying data usage for an individual SIM for a range greater than 1 day, instead of returning exact results for that range, data for the entirety of the first and last UTC hour are being included in the results. This can result in the amount being reported being higher than expected. For example, if you query usage for a single SIM from 2024-04-24 12:10 UTC - 2024-04-25 14:30 UTC you will get the same results as if you asked for 2024-04-24 12:00 - 2024-04-25 15:00 UTC. Queries with a range of 1 day (24 hours) or less for a SIM will still return results just for that range.
This behavior is different than the documented API behavior and what the API previously returned. Prior to 18:48 UTC, when querying data usage for a single SIM, you could provide start and end times that did not fall on a UTC hour and you would get partial hour results for the first and last hours. Now, usage for the entire first and last hour are being included, returning more usage than previously. Again, the results for periods of 24 hours or less continue to return correct, partial hour results.
This change was implemented due to unexpected performance issues with the underlying usage reporting system. We are investigating these issues to determine if we can restore this previous functionality. We will provide another update in 24 hours or as soon as more information becomes available.
This behavior is different than the documented API behavior and what the API previously returned. Prior to 18:48 UTC, when querying data usage for a single SIM, you could provide start and end times that did not fall on a UTC hour and you would get partial hour results for the first and last hours. Now, usage for the entire first and last hour are being included, returning more usage than previously. Again, the results for periods of 24 hours or less continue to return correct, partial hour results.
This change was implemented due to unexpected performance issues with the underlying usage reporting system. We are investigating these issues to determine if we can restore this previous functionality. We will provide another update in 24 hours or as soon as more information becomes available.
Investigating
Our monitoring systems have detected a potential issue with Super Sim. Our engineering team has been alerted and is actively investigating. We will update as soon as we have more information.
This incident affected: INTERNET OF THINGS (Super SIM).