ConnectWatch / How it works
Dashboard Sign in
Infrastructure monitoring, done right

Your server is up.
But can it actually write?

Ping says green. CloudWatch says fine. But your NFS mount silently went read-only 20 minutes ago and your users are getting errors. ConnectWatch catches what other monitors miss.

Start free trial See how it works
How it works
Four steps from setup to alert
ConnectWatch runs inside your infrastructure — it SSHes into your servers and performs real operations. No agents to install. No code changes.
1
You create an environment
An environment is a server or cloud deployment — "AWS Production", "Azure Staging". You give it a name, cloud provider, and region.
2
You add an SSH key
Create a dedicated probe user on your server with write access only to a single probe directory. Paste the private key into ConnectWatch. That's it — no agents, no SDKs.
# On your server — one time
sudo useradd -m -s /sbin/nologin probeuser
sudo mkdir -p /mnt/efs/connectwatch-probe
sudo chown probeuser /mnt/efs/connectwatch-probe
3
ConnectWatch probes on your schedule
Every 5–60 minutes (depending on your plan), ConnectWatch SSHes into your server and runs real operations — write a file, read it back, delete it. Measures each step to the millisecond.
# What ConnectWatch runs on your server
dd if=/dev/zero of=/mnt/efs/connectwatch-probe/probe.tmp bs=1k count=4 oflag=dsync
# File generated locally — no data from us
4
You get alerted the moment it degrades
If a probe fails — permission denied, disk full, filesystem hung, SSH key revoked — an incident opens immediately and you get an alert via email, Slack, or PagerDuty. One alert per incident, not one per probe cycle.
What we probe
Real operations, not just pings
Every probe type performs an actual operation on your infrastructure — not just a network reachability check.
Filesystem write
SSHes in, writes a 4KB test file using dd, reads it back, deletes it. Measures write ms, read ms, delete ms separately.
Catches: NFS/EFS mount stale, read-only filesystem, permission change, I/O latency spike, disk full
SSH connectivity
Opens an SSH connection and uploads a test file via SFTP. Measures connect time and upload time.
Catches: SSH service down, key revoked, firewall change, server overloaded
HTTPS endpoint
HTTP GET to your health check URL. Checks status code and response time. P1 severity — alerts PagerDuty immediately.
Catches: Service down, SSL expired, load balancer failure, DNS failure
AWS S3
Uploads a test object, verifies ETag, deletes it. Proves your app can actually write to S3 — not just that S3 is up.
Catches: IAM permission change, bucket policy change, S3 regional issue
Azure Blob Storage
Uploads a test blob to your container, verifies it, deletes it. Works with any Azure storage account.
Catches: Connection string expired, container deleted, Azure outage
SFTP
Connects via SFTP and uploads a test file to your configured path. For bank SFTP endpoints and file exchange partners.
Catches: SFTP down, key rejected, upload path missing
Alerts & incidents
One alert when it breaks. One when it recovers.
ConnectWatch doesn't spam you. One alert opens the incident. Probes continue silently. One alert resolves it when your fix takes effect.
Probe fails
First failure opens an incident immediately. No waiting for a second failure.
Alert sent once
Email + Slack. P1 (HTTPS) also fires PagerDuty. You get one notification — not one every 5 minutes.
Probes keep running
Subsequent failures don't re-alert. The incident stays open until your fix takes effect.
Auto-resolves on recovery
Next successful probe closes the incident and sends a recovery alert with duration.
P1 — Critical
Triggered by HTTPS probe failure. Your service is likely down for end users.
Email Slack PagerDuty
P2 — Warning
Triggered by SSH, filesystem, S3, Azure, or SFTP probe failure. Infrastructure is degraded but HTTPS may still be up.
Email Slack
Why ConnectWatch
What other monitors don't catch
Generic uptime monitors check if a port responds. ConnectWatch checks if your infrastructure can actually do its job.
Scenario Ping / uptime monitor ConnectWatch
Server responds to ping but EFS mount is stale ✓ Shows green ✓ Detects write failure — opens incident
Filesystem remounted read-only after I/O error ✓ Shows green ✓ Write fails — incident opened in next cycle
SSH key rotated, probe user locked out ✓ Shows green (port 22 still responds) ✓ SSH auth fails — instant alert
EFS burst credits exhausted — writes 10× slower ✓ Shows green ✓ Latency spike detected — Degraded status
Disk full — app can't write logs or uploads ✓ Shows green ✓ Write fails — "No space left" error in incident
S3 IAM permissions changed — app can't upload ✓ Shows green ✓ S3 probe fails — incident with exact error
HTTPS service down ✓ Detects ✓ Detects — P1 alert with PagerDuty
No data leaves your server
Test files are generated from /dev/zero locally on your server. ConnectWatch never transfers data from its side. Your data stays on your infrastructure.
Minimum permissions
The probe user has write access only to a single dedicated directory. No root access. No shell login. ConnectWatch cannot read your application data.
No agents to install
Setup takes 5 minutes. Create a probe user, paste an SSH key, done. No packages, no daemons, no code changes to your application.
No alert spam
One alert when the incident opens. One when it resolves. If your filesystem is down for 2 hours and probes run every 5 minutes, you get exactly 2 notifications.

Ready to see what your monitor is missing?

Set up your first environment in 5 minutes. No credit card required.
14-day free trial on all plans.

Start free trial Sign in