System performance
How long the service took to prepare briefings, and where the time went. This is the service's own processing time. It leaves out the telephone connection, speech recognition and speech synthesis, so it is not how long a caller waited.
Showing 1,200 synthetic requests, Mon 05 Jan 00:01 UTC to Thu 08 Jan 04:25 UTC. Dates are synthetic. Trends, Predictions and the Improvement queue always use the whole window.
Preparation time
How the times spread
Only requests with a recorded time are counted. A request with no timing record is not in any bar; see below.
Which lookups take the longest
| Lookup | Ran | Skipped | Typical time | Slowest 1 in 10 | Longest |
|---|---|---|---|---|---|
| Airport lookup | 1,017 | – | 405 ms | 603 ms | 754 ms |
| Current weather reports | 1,017 | – | 678 ms | 1.0 s | 1.3 s |
| Winds aloft table | 65 | – | 1.7 s | 2.7 s | 3.3 s |
| Hazards and pilot reports | 905 | – | 2.5 s | 4.6 s | 6.1 s |
| Weather reports along the route | 905 | – | 1.6 s | 2.7 s | 3.9 s |
| TFR list | 257 | – | 1.6 s | 2.4 s | 3.0 s |
| TFR details | 102 | 1 | 3.9 s | 5.9 s | 7.4 s |
Time is per lookup group, for the requests in this range that ran it. A lookup that could not start for lack of time is counted as skipped, not as a time.
How often a stored copy was found
Before fetching a feed the service looks for a stored copy still inside its keep-time. A found copy saves a lookup. It does not say how current the weather in it is, and nothing here is a statement about freshness.
Requests that left no timing record
54 synthetic requests in this range have no timing record. How long they took, and how they ended, is unknown. It is not zero, and they are in no time figure above.
Because this data is synthetic we can see what happened to them: {"missing_dropped":37,"missing_killed":17}. In the real service these would look the same as a request that never happened, and time figures built from records alone could lean towards the requests that finished. See Q-08.
What this page cannot tell you
How long a caller waited Not measured
This is the service's processing time. The phone connection, speech recognition and speech synthesis are outside it.
What would measure it: Timing taken on the call itself, by the phone side.
Slow or failed outside sources Not measured
The synthetic data simulates only one cause of trouble: running short of time. It does not simulate a source going down or returning bad data.
What would measure it: Real request records that include failed lookups.
Load on the host Not measured
Nothing here measures processor, memory or concurrent requests.
What would measure it: Host monitoring, which this dashboard does not read.
Engineering details: how these times are taken
Preparation time is server.script_end_ms in each record: milliseconds on a monotonic clock from the moment the request's handler began to when its work finished. It excludes anything before the handler and anything after the response.
The service works to a 15,000 ms budget and stops starting new lookups when under 1,500 ms remain. "Finished near the limit" is the record's budget.out_of_time_at_end. A lookup skipped for that reason is a fetch group with skipped_for_budget set.
Percentiles are nearest-rank over briefings and alternate-airport checks with a recorded time, refused requests and flight plans left out. The histogram puts exactly 8,000 ms in the 4-to-8 second bar, so "over 8 seconds" is the bars from 8 s upward.