GlitchTip is a popular self-hosted error tracking platform — open source, privacy-respecting, and Sentry-compatible. It captures crashes and exceptions from inside your application. Vigilmon monitors your application from the outside, the way an actual user would.
They are complementary tools, not competitors. If you run GlitchTip and nothing else, there is an entire class of failure — the kind that silences your application entirely — that you will only learn about when a customer emails you.
This article covers what GlitchTip does, what it cannot detect, and why adding Vigilmon closes the gap.
What Is GlitchTip?
GlitchTip is a self-hosted, open-source error monitoring platform. It is API-compatible with Sentry, which means you can drop it into any project that already uses the Sentry SDK. GlitchTip stores error events on your own infrastructure — making it attractive for teams with data residency requirements, privacy constraints, or a preference for avoiding SaaS vendor lock-in.
GlitchTip's core capabilities include:
- Error and exception tracking: Capture unhandled exceptions with full stack traces, breadcrumbs, and user context
- Issue grouping and deduplication: Aggregate similar errors into issues and track frequency over time
- Performance monitoring: Basic transaction monitoring for slow requests and external calls
- Uptime checks (limited): Periodic HTTP pings with simple up/down alerting
- Alerts: Notify on new issues or error volume thresholds via email or webhook
GlitchTip's uptime check feature sends a basic HTTP ping from its own server. It tells you whether a URL returns an HTTP response. That covers a subset of what production uptime monitoring needs to cover, and it lacks several features that matter when things break at 3 am.
What Is Vigilmon?
Vigilmon is a purpose-built external uptime monitoring service. It does not integrate with your application code. It does not receive error events from your SDK. It continuously probes your endpoints from multiple geographic regions and alerts you the moment a probe fails — before a single user has to experience the outage.
Vigilmon's core capabilities include:
- HTTP/HTTPS endpoint monitoring with status code validation
- TCP port monitoring for non-HTTP services
- Cron job heartbeat monitoring (dead man's switch pattern)
- Multi-region consensus alerting — fires only when independent probes across multiple locations agree the target is down, eliminating false positives from regional blips
- Response time history with configurable period selectors
- SSL certificate expiry monitoring and alerting
- Webhook, email, and Slack alert delivery
- Customer-facing status page included at no extra cost
- REST API for programmatic monitor management
There is no SDK to install. No agent to deploy. No configuration inside your application. Just probes confirming your services are reachable from the open internet.
The Critical Difference: Inside-Out vs Outside-In
GlitchTip's error tracking is inside-out: it relies on your application producing an event. If your application crashes completely — the process dies, the server runs out of memory, the load balancer stops routing — GlitchTip receives nothing. Silence. A full outage and a perfectly quiet system look identical from GlitchTip's perspective.
Vigilmon is outside-in: it sends requests to your service on a schedule regardless of whether your application is healthy. If the server is unreachable, the probe fails. Vigilmon does not need your code to run to know your service is down.
| Failure scenario | GlitchTip sees | Vigilmon sees | |---|---|---| | Application exception on request | ✅ Full stack trace | ✅ HTTP 500 from probe | | Process crash / full outage | ❌ Nothing | ✅ Probe fails, alert fires | | DNS resolution failure | ❌ Nothing | ✅ Probe fails, alert fires | | TLS/SSL certificate expired | ❌ Nothing | ✅ Certificate alert fires | | Load balancer routing failure | ❌ Nothing | ✅ Probe fails | | CDN serving a cached error page | ❌ Nothing | ✅ Probe detects non-200 | | Database connection pool exhausted | ✅ DB timeout exceptions | ✅ Response time degrades | | Cron job stopped running | ❌ | ✅ Missed heartbeat, alert fires |
The failure modes that cause the most customer impact are full outages — the ones where GlitchTip receives no signal at all.
Where GlitchTip's Built-in Uptime Checks Fall Short
GlitchTip includes a basic uptime monitoring feature, but it is architecturally different from what Vigilmon provides:
| Capability | GlitchTip uptime checks | Vigilmon | |---|---|---| | Number of probe locations | Single region | Multiple geographic regions | | False-positive suppression | None | Consensus quorum required | | TCP port monitoring | ❌ | ✅ | | Cron job / heartbeat monitoring | ❌ | ✅ | | SSL certificate expiry alerts | ❌ | ✅ | | Response time history and trends | ❌ | ✅ | | Customer-facing status page | ❌ | ✅ | | Webhook / Slack delivery | Limited | ✅ | | REST API for monitor management | ❌ | ✅ |
A single-region uptime check will produce false positives when the probe location experiences network issues unrelated to your service. Vigilmon's multi-region consensus approach eliminates this noise — you only get alerted when a quorum of independent probes agree that the target is genuinely unreachable.
What a GlitchTip + Vigilmon Stack Looks Like in Practice
Example: a self-hosted SaaS application
You run GlitchTip for error visibility during development and deployments. You run Vigilmon for continuous external availability verification.
- GlitchTip catches the
NullPointerExceptionin your payment flow before it impacts more than one user - Vigilmon catches the deployment that failed silently — the app never came back up after a restart, GlitchTip saw nothing
- Vigilmon alerts on the SSL certificate that expired at midnight — no user request reached your app to trigger a GlitchTip event
- GlitchTip traces the slow database query that is degrading checkout; Vigilmon simultaneously reports rising response times on the same endpoint
- Vigilmon pings your status page webhook when an incident starts; your users know before they email you
Example: a privacy-first API product
You chose GlitchTip precisely because it is self-hosted and keeps your error data on your infrastructure. Vigilmon is also compatible with that philosophy — it probes your public-facing endpoints from the outside and does not see your application internals.
Setting Up Vigilmon Alongside GlitchTip
Getting started takes under five minutes:
- Sign up at vigilmon.online — free plan available, no credit card required
- Add your primary endpoint: enter your application URL, set the expected HTTP status code (200), and choose your check interval (1, 3, 5 minutes)
- Add a TCP monitor if your service exposes non-HTTP ports (database, SMTP, MQTT)
- Configure a heartbeat monitor for any cron jobs your application depends on — paste the Vigilmon ping URL into your job script
- Set up your status page — Vigilmon provisions a public status page automatically; share the URL with your users
- Connect Slack or webhooks — send alerts to your existing incident channel
GlitchTip handles what happens inside your application. Vigilmon handles whether your application is reachable at all. Together they give you complete visibility.
Who Should Run Both?
- Self-hosted application teams who run GlitchTip for privacy or cost reasons and need external uptime coverage without adding a heavy SaaS monitoring platform
- Indie developers and solo founders who need visibility into whether their deployed service is up at night and over weekends
- Open-source projects with self-hosted instances that want to give users a status page showing current availability
- Privacy-first SaaS companies who need external monitoring that does not require embedding third-party SDKs or exporting internal application data
- Any team already using GlitchTip that has experienced an outage they only heard about from a user rather than from their monitoring
Try Vigilmon Free
Vigilmon's free plan covers monitors for small projects with no credit card required. Paid plans add more monitors, shorter check intervals, and additional team members.
If you already run GlitchTip, adding Vigilmon closes the monitoring blind spot that error tracking cannot see: whether your service is actually reachable from the internet.