howfast / roadmap Goto Github PK

For now, all targets are monitored every minute. This is great, and usually a paid feature on other monitoring tools.

However, you may need to monitor even more frequently your applications, to detect downtimes (this can be especially useful to check if zero-downtime deployments are actually holding their promises) or detect performance issues. On the other end, you may also need to reduce the frequency on non-vital targets.

This feature would let you choose the monitoring frequency, on a per-monitor basis, among the following frequencies:

• 10s
• 15s
• 30s
• 1min
• 2min
• 5min
• 30min

Let me know if you think this feature should be prioritized, and I'll start working on it right away! 🚀

Sometimes, we don't want to be notified of small downtimes (usually less than a minute). HowFast's default monitoring interval being 60s, it often catches these small downtimes, notifying the user / team. While some users may want to get ultra-fast notifications when their server looks down, some others may want to wait for a little longer to make sure the downtime is not temporary, thus avoiding spam.

Some "notification filters" could help satisfy this category of users:

• "only notify if more than 3 consecutive failed pings"
• "only notify if more than 4 failed pings over the last 30 pings"

Use case: monitors with a low uptime standard, ...

Initial reporter: @jpcaruana

I think no decimals are needed (or only two) in the detailed view:

• AVG values :

• all values :

Need: to get a periodic overview of the general performance and/or major events on a given set of monitors.

This may include:

• mean response time
• number and nature of downtime
• uptime % or downtime minutes
• major events (response time dropped by 20% compared with last week)

Display channels:

• in www.howfast.tech
• by email
• directly in Slack (my favorite so far)

Any comment from the community is welcome! 📣

Need: ability to choose the location from where to test a given target: Paris, Tokyo, Sydney, San Francisco, etc. For now all targets are monitored from Paris, France North California, USA.

The first step could be to let users monitor a target from one location.

Next steps may include the ability to monitor a target from multiple locations (check the boxes for the chosen locations).

If this feature can solve your need, which location(s) would you like to see available first?

To better understand how our applications perform, we need to see the split time:

• DNS request
• TCP connection
• TLS handshake, if applicable
• HTTP request send (time took to send the request)
• HTTP wait (time to first byte)
• HTTP receive (time took to download the response)
• time spent in redirects

• collect and store these metrics
• design the UI to incorporate the information in an easy-to-see way (stacked graph?)

It would be great to be able to access monitor data (response times mainly) from a Prometheus instance in order to integrate it in our standard monitoring tools

Your server has 100% uptime? Answers blazing fast? Show it off to your clients, collaborators and team members with these little badges.

For now, uptime badges are available in PNG or SVG format:

Other badges have been designed but have not yet been implemented due to lack of demand:

Let me know if you like this feature and which badge you would adopt in the comments!

for some URL only accessible behind a gateway, it would be great to have the option to add API Key (HTTP header with key/value for instance)

My current need is a X-Gravitee-Api-Key header

Right now, the APM features shows the Average response time for every single route

This is great, but an average is not enough to understand what is happening. It would be great to have more statistics about every route:

• number of hits
• median / min / max
• standard deviation etc

howfast tells me Monitor is DOWN for certificate signed by unknown authority reason.

It would be great to mark it as UP (or warn) but not down. The site is in fact UP with a known issue on certificate or to be able to ack the issue ("I know I have a certificate signed by unknown authority") and keep on monitoring the server

yes I can

DNS resolution time is sometimes quite variable, while being usually out of control from the user / tracked server.
I propose using a local resolver, controlled by HowFast, to maintain a quality and consistency in response times.

Important note: while using the provider's (or public) resolvers is closer to what a real user will experience, such records are usually cached by the browser or HTTP clients (and not in HowFast pings), so this "realism" is not very efficient at assessing the performance of an application. The average time spent resolving DNS will still be linked to the record's TTL, as small TTLs will lead to the local resolver asking authoritative servers more often, thus taking more time. This behaviour is nevertheless shared by all the targets monitored: the TTL expiration will only cause one monitor to record the increased resolution time, while others will not see any difference. This behaviour is deemed acceptable, since maintaining one DNS cache per monitor makes little sense.

Like on monitors,

It would be nice to be back on the list of all APM

For now, it is not possible to see if and how a given target redirected the user, unless redirects are forbidden (default option).

This feature let users see the redirect chain for a given monitor.

• store this information
• design where and how the chain is displayed

Please upvote if you would like to see this feature shipped soon!