Most changes in a shop go unnoticed at the moment they happen. TTFB climbs on a Tuesday evening, traffic drops after a DNS change, a release brings more JavaScript errors. All of it is in the dashboard. You just have to look at the right chart at the right time.
We work on fastmon every day, on bug fixes, on the interface, on new features. Much of it you never see. Today we want to show you something you should see: Observations, available now as a beta.
fastmon compares load times, errors and traffic around the clock with what is usual for your application. When something changes clearly, fastmon opens an observation by itself, with its start, its end and the numbers behind it. There is nothing to set up.
Until now, only we at fastmon could see observations, as an internal preview. From today they are available to every role in your organization, as long as Watchdog is enabled for your organization. You find them in the sidebar under Observations.
Usual means your application, not a threshold
A fixed threshold tells you whether a value is bad. It does not tell you whether it changed. A shop that usually answers in 400 ms and suddenly takes 1,200 ms has a problem, even though 1,200 ms is still below the cutoff for “poor”. That is why fastmon compares your application with itself.
There are two kinds of observations: shifts for the sudden and trends for the gradual.
Shifts: what changes within a quarter hour
A shift compares a quarter hour with the same quarter hour on the previous seven days, with their median to be precise. So Tuesday 20:15 to 20:30 is compared with 20:15 to 20:30 on the seven days before. That way the perfectly normal evening peak does not stand out, but a drop at 20:15 does.
What is compared:
- Traffic, meaning human page views. A drop is a degradation, a rise only a note: behind it is a bot wave that was not recognized as one just as often as real visitors.
- TTFB and LCP, each as the p75 in milliseconds.
- JavaScript errors, as the share of page views with an error from your own scripts.
- Bots, meaning page views that do not come from people. Every change here is a note, because a crawler coming or going costs you no visitor.
A clear degradation, three times the usual value or, for traffic, a drop to a third of it, shows up after 30 minutes, after the second unusual quarter hour in a row. Everything else appears once it has lasted two hours: improvements, notes and degradations that sit “only” at twice the usual value. So that a quiet quarter hour triggers nothing, each one needs at least 150 page views, 500 for bots. And since the comparison needs a past, a new application shows no shifts during its first four days.
For every shift towards degradation and for every traffic or bot shift, the observation also shows you where it happens: by country, page type, device and domain. Plus the releases that went live around its start.
A shift ends by itself once a quarter hour is close to the usual value again. If it lasts four days or longer, it ends as well: by then the new value counts as normal. If the same change comes back at the same time of day within seven days, it stays one observation, “Shift, recurring”, with every single occurrence listed in it.
Trends: what moves over weeks
Not everything tips over within a quarter hour. Some things get a little worse every week: one more image here, one more script there. No single day stands out, and that is exactly why nobody notices.
A trend compares the last seven days with the 14 days before. It looks at LCP, INP, CLS and TTFB, each as the share of page views in the poor range, plus the error share. A trend opens when that share reaches 1.3 times its level in the 14 days before and grows by at least two percentage points. The same holds the other way round for an improvement. The evaluation runs once a day, at midnight UTC. The trend ends at the first midnight at which the last seven days are below 1.1 times that level again.
An open trend also tells you since when the metric has been on its new level, as “since at least” a given day. That is the question you ask next, because you want to match that day against your deploys. “At least”, because the trend only knows the last seven days: it may well have started earlier.
Acknowledged, with a note for your team
An observation someone is already working on should not keep jumping at everyone. “Acknowledge” at the top right takes it out of the open observations and the counter in the sidebar. You can add a note for your team, up to 1,000 characters. For example: “Caused by yesterday’s release, the fix is on its way.”
Acknowledged does not mean resolved. The observation still ends by itself once the values are back to normal, and the note stays after that. When a recurring shift comes back, it stays acknowledged. Owners and members can acknowledge. Viewers see what has been acknowledged but cannot acknowledge themselves.
What observations do not do
Observations send no notifications. They are in the dashboard when you look. The weekly mail does pick up the trends, though, if you receive it: open degradations and the week’s improvements.
And it is a beta. We tested the thresholds against real data and tightened them. They may still change all the same, just like the texts and the layout of the page.
Tell us what you see
Right now we learn the most from the observations that do not fit: one that came too early, one that was missing, one whose text left you puzzled. Write to us through “Send feedback” in the dashboard, and tell us how you use observations in your monitoring. Every rule in detail is in the documentation.