The Developer's Guide to Modern Observability: Uptime, Live Logging, Better Stack & Axiom
Observability is the practice of understanding the internal state of a system based on its external outputs (logs, metrics, and traces). This guide covers the core fundamentals, system architectures, and practical applications of modern monitoring tools, focusing on Better Stack and Axiom.
When we deploy an application, especially a Next.js application, our job does not end when the deployment succeeds. This is where monitoring and observability come in.
We will be using two tools:
Better Stack Uptime to know whether our application and services are available and to alert us when something goes wrong. Axiom to collect, search, analyze, visualize, and monitor the telemetry produced by our application.
Better Stack's Uptime platform performs checks against services from outside, similar to how a real user would reach them. Axiom focuses on collecting and analyzing timestamped telemetry such as logs, traces, metrics, and events.
Monitoring vs Observability
Better Stack describes monitoring as the automated checking of whether a service is available. Its HTTP status monitor periodically checks a URL and creates an incident when the expected successful response is not received.
Monitoring tells you when something is broken.For example: "CPU is at 99%." .Observability allows you to understand why it is broken. For example: "Why did the database query fail for user X after the last deployment?"
It provides the context needed to debug novel and complex problems. Logs, Metrics, and Traces Logs — The "Why" A log is a record that something happened in your application. Logs are structured or unstructured text events recorded during system execution. They provide timestamped records of specific events. For example: "cuid-user-123 logged in from IP X" Metrics — The "Whether"
Metrics are numeric values aggregated over time. For example: CPU load Active database connections Memory usage
Metrics are highly efficient for dashboarding. Traces — The "Where" Traces represent the end-to-end journey of a single request through a distributed system. For example, a checkout request may show that it spent: 20ms in middleware, 150ms in server logic, 800ms waiting for the database Uptime
Uptime is the amount of time a service is available and functioning. The opposite of uptime is downtime. Total service time is the summation of uptime and downtime.
Total service time = Uptime + Downtime
Uptime Monitoring Uptime monitoring simulates real user behavior to check if your application is alive, responsive, and functioning.
Every X seconds, usually 30 or 60, it makes an HTTP GET request to your application. It then asserts that the response meets specific criteria, such as: Status Code = 200 OK
If the ping fails, the monitoring system pings it from a different global region to rule out local routing failures. If both fail, an incident is created.
Heartbeat / Cron Monitoring
Traditional ping checks are pull monitoring because the monitoring service is the one that pings your application.
But what if a background sync script or database backup cron job fails to run? You cannot ping a script that only runs once a day. For this, we use push monitoring (Heartbeats).
How Heartbeats Work You configure a unique heartbeat URL on your monitor.
https://uptime.betterstack.com/api/v1/heartbeat/abc123xyz At the end of your script execution, the script sends an HTTP GET request, or a "ping", to that URL. If Better Stack does not receive the ping within the expected time window, it alerts you that the backup script failed to run.
For example, if the script is expected to run every 24 hours, we can configure the heartbeat with a 24-hour interval and a grace period.
Incidents Better Stack describes an incident as the central record for a service disruption or performance issue, covering its lifecycle from detection through resolution.
Incidents can be triggered by:
monitors heartbeats integrations users the API
An acknowledgement indicates that someone has taken ownership of the incident. Resolution means that the underlying problem has been fixed.
Alerts An alert is the notification that tells you: "Something requires your attention."
Status Page A status page is a public or private page where users can see the state of your services.
Standard Log Levels To keep logs readable, systems organize log outputs by priority.
DEBUG: Low-level verbose details, useful in development. INFO: Normal, expected operation milestones, e.g., user logged in, sale logged. WARN: Unusual events that aren't errors but could lead to issues, e.g., database connection pool reaching 80% capacity. ERROR: Runtime failures affecting a request, but the application continues to run, e.g., user login failed, Prisma constraint validation failed. FATAL / CRITICAL: Severe crashes that stop the system entirely, e.g., server port already in use, main database connection down. Axiom
Axiom is an observability platform designed to ingest, store, query, visualize, and monitor event data.
Its current platform supports: logs; traces; metrics and events
It also provides: querying, dashboards, and monitors
Axiom does not use standard SQL. Instead, it uses a pipe-delimited query language called APL.
The pipe character is:|
APL is used to query and analyze the telemetry produced by our application
Part 1: Setting up Uptime Monitoring (Availability Alerts) This checks if your website is online and calls/texts you if it goes down.
Create an Account: Go to BetterStack.com and sign up for a free account. Create a Monitor: On your dashboard, click Monitors in the left sidebar .click Create monitor. Enter your Domain: URL to check: Enter your Vercel deployment domain (e.g., https://yourdomain.com). Alert us when: Select If status is not 200 OK. Configure Notification Channels: Select how you want to be alerted when the site goes down (e.g., Email, SMS, or Phone call). The free tier includes free email and SMS alerts.
Save Monitor: Click Create monitor. Better Stack will now ping your LedgerLite app every 30 seconds from global servers. NB: The Uptime Monitor only checks the availability of your homepage (e.g., pings GET https://yourdomain.com every 30 seconds). if you get errors on login, it won't alert you. unless your domain becomes out of service
To test your uptime alerts and verify that your phone/email notifications are set up correctly, you can easily simulate a site outage without touching your actual codebase.
Go to your Better Stack Uptime dashboard.
Find your monitor, click the three dots → select Edit. Change the URL to check to: https://httpstat.us/500 (This is a free developer utility that always returns a 500 Internal Server Error when pinged). Click Save. Within 30 to 60 seconds, Better Stack will ping that URL, detect the 500 error, and trigger the alert.
Go to your Better Stack Logs dashboard. Click on Alerts in the left sidebar → click New alert rule. Set the condition to scan your logs for serverless errors: Filter query: level:"error" OR status:500 Set the notification channel (Email/Slack/SMS). Click Save.
Now, if a database connection fails or a script crashes, the log is caught by Vercel, streamed to Better Stack, and triggers your alert!
When the outage is detected, this is the exact flow that will occur:
Double-Checking (No False Alarms): Before sending you an alert, Better Stack's server in the US will ask a server in Europe or Asia to double-check the ping. This ensures it isn't just a temporary routing glitch.
Alerting You: If the check fails again, the incident is officially opened. You will immediately receive: Email: An email saying: [Incident Opened] Monitor httpstat.us/500 is DOWN.
SMS/Phone Call: If you configured phone alerts, your phone will ring or receive a text stating the server is down. Status Page Update: If you created a public status page, it will automatically turn Red and show
If you want to be notified when the server actually crashes or the database connection drops (returns a 500 error), you use Better Stack Logs:
optionally you can Create a Public Status Page You can create a beautiful status page to show your team or customers that LedgerLite is fully operational:
Click Status Pages in the left sidebar. Click the Create status page button in the top right. Fill out the setup form: Name: LedgerLite Status Subdomain: Enter a unique name, like ledgerlite (this will create your free public link: https://ledgerlite.betteruptime.com). Click Create status page.
Then Link your uptime monitor/heartbeat
Once you click create, Better Stack opens the settings dashboard for your new status page. It is blank by default. We must add your monitor to it: In the status page settings, scroll down to the section named Active sections / Resources. Click the Add monitor / heartbeat button. A dropdown list will appear. Select the checkbox next to your LedgerLite uptime monitor. Click Add. Crucial Step: Scroll to the bottom of the page and click the green Save changes (or Publish) button.
Step 4: Test your Public Link
Now, click the public URL shown at the top of your settings page (e.g., https://your-chosen-subdomain.betteruptime.com).
You will now see a clean, public status page displaying:
A green bar showing "All systems operational". A 90-day history bar of your site's uptime. A response time latency chart.
Your can use it in the following ways:
- Add a small, clean link in the footer of LedgerLite (e.g., next to "Terms" or "Privacy") that says "System Status" or "Operational Status" linking directly to your Better Stack page.
Why? If a user experiences a slow load time or sync delay, they can scroll down, click "Status", and see if it's a server issue or just their own local internet connection.
- Put it on your Support / Help Page If you have a support form or a contact email, add a message above it: "Having trouble? Please check our System Status Page before submitting a support ticket."
Why? This prevents you from getting flooded with hundreds of identical support emails during a temporary server restart or database migration.
Comments (0)
No comments yet. Be the first to share your thoughts.