Colloquially it is all called "monitoring": knowing whether your application works. But there are two different questions behind that one word, and mixing them up means missing exactly the outage that hurts. One asks whether the service is up; the other asks what went wrong while everything was up.
What monitoring answers
Monitoring looks at your system from the outside and from below: is the server reachable, is there disk space and memory, does the site respond within normal time, is the certificate still valid. The answer is a state, and the value is in the alarm: you hear it when something goes from healthy to unhealthy, preferably before users notice anything.
What error tracking answers
Error tracking looks from the inside: the application reports every error itself, with stack trace, release and context. That catches the outages monitoring is blind to — the payment button failing for everyone with an accent in their name, the export file that has been empty since the last release. The server is healthy, the site responds briskly, every light is green; yet something is broken for part of your users, and without error tracking you hear about it when someone calls.
One's blind spot is the other's territory
Monitoring sees the server die but not the exception; error tracking sees the exception but not the full disk. Stronger still: when the server goes down, error tracking goes down with it, because it runs on the application that just disappeared. These are not competitors to choose between, but two layers that cover each other's gaps. A healthy environment has both, and alerts from both should arrive in the same place, so nobody has to watch two dashboards.
Both, by default
Applications we build and run get both as part of delivery: monitoring on the infrastructure, error tracking in the application, alerts on one channel. If you honestly do not know what would be reported today if something in your application broke: get in touch and we will map it out together — or first read how we deliver software.