DockRay
Monitoring for applications, online stores and websites: production errors, uptime, SSL certificates, performance and vulnerabilities in plugins and modules.
- Type
- SaaS product · monitoring and security
- Period
- in development
- Product website
- dockray.io
My role
My role
My contribution
I’m responsible for the system architecture, the alerting model and decisions about how error and vulnerability data is processed.
The team’s work
DockRay is built by the Dock team. The SDKs, plugins for popular platforms and integrations are a team effort.
Decision line
An alert should signal a deviation from the norm, not every single error.
- Context
Alert fatigue
Systems that notify you about every error quickly teach people to ignore notifications. Then the important alert gets lost in the noise.
- Choice
Deviation-based alerts
Errors are grouped, and a notification goes out when their number departs from the typical level for that project.
- Trade-off
Not every error wakes someone up right away
A single, rare error can wait for the next review. That’s a deliberate decision, and it has to be communicated clearly to users.
- Takeaway
Fewer notifications, more action
Alerts mean something again. I’m leaving the details of thresholds and rules out of this description because they’re security-related.
DockRay
DockRay
DockRay grew out of a need I know from maintaining many projects: you have to know something is breaking before the client tells you.
According to the product website, DockRay tracks production errors, uptime, SSL certificates, performance (including Core Web Vitals) and vulnerabilities in plugins, themes and modules. It offers SDKs for PHP, Python and Node.js, a REST API and ready-made plugins for popular platforms, and it stores data on servers in the European Union.
From an architect’s point of view, the most interesting decisions here are about when to interrupt a human. Monitoring that alerts on everything is almost as useless as no monitoring at all.