Skip to content

Infrastructure & Integrations

Observability and monitoring: hear it from the system, then find out why

Most businesses find out their software is broken when a customer calls. By then the question is not only what's wrong but how long it's been wrong. We instrument systems so the right person hears first and can answer why: an alert says something changed, a trace of one request shows where the time went, and the log says what happened there.
Talk through what you can't seeSee the signals worth collecting ↓
booking time · this eveningbookings slower than usual3.8 s · usually 0.4 s · 7:42 pmfix released · 8:31 pm1 s time limit · areas kept for a dayone slow booking · R-118 · 3.8 sbooking requestsign-in checkrule checkservice-area lookup3.4 s · no time limitsave bookinglog · map service slow to answer · waited 3.4 s · no time limit set

Five signals worth collecting

Each answers a different question. Together they let someone go from “something's wrong” to “here's why”.

  1. 01

    Health checks

    Is it up?

    The site, the app and each connected service checked every minute from outside.

  2. 02

    Errors

    What broke, for whom

    Each error grouped with the others like it, with the screen, the release and how many people it hit.

  3. 03

    Traces

    Where the time went

    One request followed through every step it took, so a slow lookup stands out from the fast ones.

  4. 04

    Logs

    What happened there

    Structured lines tied to the request they came from, searchable instead of scrolled.

  5. 05

    Costs

    Including AI usage

    Hosting, database and AI model costs per feature, so a runaway bill shows up in days, not at month end.

Alerts that mean something

An alert that fires every day gets ignored. Each one here has a threshold, an owner and a first step.
Site or app downtwo checks in a row failcheck the status page; switch back to the last release if it was a release
Bookings slower than usualmuch slower than usual for 5 minutesopen a slow booking's trace
Errors after a releaseerrors rise within 15 minutes of a releaseswitch back to the last release
Jobs failingthe same job fails 3 timesread the job's reason; fix or hand to the office
AI costsa day's usage double the usualfind the feature in the cost breakdown

One slow evening, followed

One incident, as the record shows it. No customer had to call.
  1. 7:42 pmalert.firedBookings slower than usual: 3.8 s, usually 0.4 s. Developer on call notified.
  2. 7:46 pmtrace.openedBooking R-118: 3.4 s in the service-area lookup
  3. 7:49 pmlog.foundMap service slow to answer; the lookup had no time limit
  4. 8:31 pmfix.released1 s time limit; service areas kept for a day so the map service is rarely asked
  5. 8:36 pmalert.resolvedBooking time back to 0.4 s
  6. next daynote.writtenWhat happened, what changed, and a new alert for the map service

Logs nobody reads, or questions answered

Logs nobody reads

  1. 01Text files on a server
  2. 02An error email nobody opens
  3. 03No way to follow one request
  4. 04Costs seen on the monthly bill

Customers report problems, and nobody can say why they happened.

Questions answered

  1. 01A few alerts, each with an owner
  2. 02Errors grouped, with who they hit
  3. 03Any slow request opened as a trace
  4. 04Costs per feature, watched daily

Is it up, did it work, why not, how long, what did it cost: each has an answer.

What monitoring watches

In

Site and app
health, errors, traces
Jobs and services
failures, slow calls
AI features
usage and cost
Monitoring
compare with usual, decide who

Out

Alerts
to the owner
Dashboards
for the team
Incident notes
what happened, what changed

Worth doing once customers or staff depend on the software

Good fit

  • You hear about problems from customers.
  • Nobody can say why the app was slow yesterday.
  • AI or hosting costs surprise you each month.

Not the right fit

  • A website with no logins or bookings. A simple uptime check is enough.
  • You need to know whether each automation run finished. That's workflow monitoring and recovery.

Where this capability is used

Next to monitoring

Questions about observability and monitoring

What's the difference between monitoring and observability?

Monitoring tells you something is wrong. Observability lets you find out why, without adding new code first. You need both, and they use the same signals.

Who gets woken up at night?

Only alerts that need someone that night go out at night, to whoever you've agreed is on call. The rest wait for the morning.

Can you add this to our existing software?

Usually, yes. Health checks and error tracking go in first, then traces and logs for the parts that matter most.

Does this slow the software down?

Not noticeably when it's set up well. Traces are sampled, and the most detail is kept for slow or failed requests.