We find out about the failure before your customers do.
Who it is for
For companies and public bodies with a website, a portal or an application their customers or their team depend on, and who today hear about failures when someone calls.
The problem
You find out the website is down because a customer writes to you. The certificate expired on a Sunday. There is an error that only some users have been hitting for months and nobody has seen it, because nobody reads the logs.
How we solve it
We check from the outside that everything responds and, from the inside, every error that occurs. For every new error, an agent opens an issue with what happened and prepares the fix. A person reviews it before it reaches production. You get the alert along with what has already been done.
What it includes
Availability
We check from the outside that your website and applications respond, and how long they take.
Certificates
We watch their expiry, with a warning before they run out.
Errors
Every application error is captured, grouped and kept with its context.
One issue for every new error
An agent opens it, with the likely cause and the steps to reproduce it.
A prepared fix
The agent proposes the change; a person reviews and approves it.
Alerts and a monthly summary
An automatic alert when something fails and a report of what happened.
How we work
At the start we agree what is monitored, who is alerted and how. We connect the monitoring and clear out the noise of the first weeks, so that an alert means something. After that, every new error follows the same path: issue, proposed fix, review by a person and deployment. The monthly report shows what failed and what was fixed.
What we measure
Availability, response time, new errors and resolved errors, time from an error appearing to it being fixed, and days left before each certificate expires.
How it is built
On every project we monitor availability, response time and SSL certificate expiry, with automatic alerts. The checks run from the outside, the way a user would.
Browser and server errors are captured with GlitchTip, which is compatible with the Sentry protocol. Personal data is stripped before they are stored: to fix a failure you need to know what happened, not to whom.
When an error appears that has not been seen before, an agent reads it, finds where it comes from in the code and opens an issue in GitLab with the stack trace, the likely cause and how to reproduce it. It then prepares the fix on a branch, with its test. It does not publish it: the change goes through the same tests as any other and a person approves it.
Repeated errors are grouped into a single issue, so the board does not fill up with identical alerts. The agent works with the least access it needs and has no access to production credentials.
Frequently asked questions
Does the agent fix errors on its own?
No. It opens the issue and prepares the fix. A person reviews it, approves it and decides when it goes live.
How do I find out about a failure?
Through an automatic alert on the channel we agree at the start, and through the summary in the monthly report.
What happens to personal data that shows up in an error?
It is stripped before the error is stored. What is kept is what is needed to reproduce the failure.
Does it work for an application you did not build?
Yes. Availability monitoring does not need to touch anything. Capturing errors means adding a small component to the application.
Also in Managed systems
Backups
Encrypted and tested: we actually restore them, not just copy.
Deployments
Every change goes through tests before production, with rollback.
The next step
Tell us how you work today and we will tell you where to start.