Monitoring and on-call

Most of the outages we inherit were not caught by an alert: they were reported by an unhappy customer, often days later. The opposite exists too, more insidiously: monitoring that sends so many alerts nobody reads them any more. An alert should be rare, accurate, and say what to do. We watch uptime, application errors, server resources, and above all what nobody watches: the overnight jobs that were supposed to run and no longer do.

What you get

Deliverables

• check_circleThe probes in place, with thresholds written down and discussed
• check_circleCentralised, searchable logs
• check_circleThe alerting channel: who is notified, how, within what delay
• check_circleA written report after each incident: what happened, what will stop it recurring

Frequently asked questions

Do you respond at night and at weekends?

Depending on the contract. We would rather be straight about it: genuinely round-the-clock on-call requires an organisation a small firm cannot seriously promise. What we can hold, we put in writing; what we cannot, we do not sell.

How long are logs kept?

One month by default, which comfortably covers incident diagnosis. Longer where a regulatory obligation requires it — in which case the duration is decided alongside the processing register, not at random.

Will you monitor an application you did not write?

Yes. Uptime, certificates, resources and scheduled jobs can be watched from outside, whatever the technology. Fine-grained application error monitoring does require access to the code.