About PodUptime
PodUptime is a distributed uptime monitoring system for the podcast industry, measuring availability of hosting platforms and tracking prefixes.
How does it work?
The measurement process involves regularly conducting an HTTP HEAD request against
a media enclosure URL, which is typically found in podcast RSS feeds.
We gather data from various AWS regions, each of which performs an HTTP HEAD
request every minute on every monitored service. These regions include us-west-1,
us-east-2, and eu-south-1, carefully chosen to avoid regions where
most companies typically run their workloads, ensuring an unbiased measurement.
The User-Agent being used to perform these requests is:
Mozilla/5.0 (compatible; PodUptimeBot/1.0; +https://poduptime.com; rid:XXX). The rid
property represents a random GUID (eg: 0e7f5251-9d03-4371-8186-a82ca9c5235e) which
is utilized to persist the request results in our internal database, facilitating debugging
purposes. Additionally, it ensures that consecutive checks conducted on the same endpoint are
not treated as originating from the same listener, in accordance with the IAB definition, and
prevents short-circuiting of a pre-existing cached response.
How is availability established?
Availability is established differently based on the type of the target:
- Tracking prefixes are considered
UP if they promptly redirect to the prefixed
URLwith one of the followingHTTPstatus codes:301,302,303,307, or308. The redirection itself is not followed, ensuring that the measured duration represents the actual time it takes for the prefix to initiate the redirect. - Hosting platforms are considered
UP if they respond with an
HTTPstatus code200to a request made to the monitored URL, following any redirects. In this scenario, the measured duration reflects the actual time it takes for the client to reach the destination of theHEADrequest.
The status shown in the homepage represent the availability over the last 30 minutes and it is reported as follows:
| Status | Availability |
|---|---|
| UP | The endpoint consistently showed as UP |
| PARTIAL | The endpoint was detected as UP in certain regions or moments and as DOWN in others |
| DOWN | The endpoint consistently showed as DOWN |
| UNKNOWN | No data is available for the endpoint |
Furthermore, to minimize false positives and ensure fairness in our measurements, an endpoint is classified as DOWN only when two consecutive measurements from the same region confirm its status.
Why is a particular hosting platform / prefix missing?
It's possible that we may have missed it, or the specific platform might not allow the creation of a free account, and we do not have an existing one to use. Please get in touch with us via email at poduptime@spreaker.com, and we will do our best to incorporate your chosen platform or prefix.
I see this is made by an hosting platform, is it biased?
Every service we monitor receives equal visibility, and the testing methodology is explained in detail. If you find this information insufficient, you can review the source code of the project on GitHub. We believe that releasing the code as open source addresses any concerns or doubts about fair measurement. However, if you still have any questions or require further clarification, please feel free to get in touch, and we'll be happy to assist.
Do you keep a changelog?
Yes, we maintain a Changelog where you can review all the changes that have been implemented in this monitoring system over time.
I have other questions, how can I reach out?
Please send us an email at poduptime@spreaker.com