title: "Verify Redis from your web tier" description: "TCP uptime check that runs from your own web servers, not from BoxWatch's network. Confirms what your app actually sees." last_updated: "2026-05-24"

Verify Redis from your web tier

Your web servers depend on Redis. You want to know when Redis becomes unreachable — but from the perspective of the boxes that actually talk to it, not from some third-party probe network sitting on the other side of the public internet.

This recipe sets up a TCP uptime check that originates from your own web-tier servers and reports back to BoxWatch.

Why agent-side, not SaaS-probed

Most uptime services probe from their hosted infrastructure. That tells you "Redis is reachable from us-east-1.someprovider.cloud." It does not tell you whether Redis is reachable from your application servers, behind your VPC, through your security groups.

BoxWatch's uptime checks run on the agents you've already installed. You assign the check to specific servers ("probe from web-01, web-02, web-03") and each one opens the TCP connection itself, then reports the result. The aggregate of those results is what BoxWatch alerts on. See the Uptime docs for the longer rationale.

Prerequisites

• Pro plan or higher (uptime checks are a Pro feature).
• BoxWatch agent installed on at least one web-tier server. Three is better — see the multi-vantage notes below. Install instructions at Installing the agent.
• A Redis instance reachable from those web servers at a known host:port. We'll use redis.internal:6379 in examples.

Step 1: add a TCP uptime check via the dashboard

1. Dashboard → Uptime → New check.
2. Name: Redis from web tier.
3. Check type: TCP.
4. Target: redis.internal:6379 (host:port format).
5. Timeout: 5 seconds. Redis on a healthy network responds in milliseconds; 5 seconds is generous.
6. Probe servers: pick all your web-tier servers. The check runs once on each.
7. Save.

The check will start running on each server's next heartbeat (every minute on Pro/Team/Scale, every hour on Hobby — but you're on Pro because the feature requires it).

Step 2 (API alternative)

If you'd rather script it:

export TOKEN="bw_..."
 
curl -fsS -X POST https://api.boxwatch.app/uptime-checks \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Redis from web tier",
    "check_type": "tcp",
    "target": "redis.internal:6379",
    "timeout_seconds": 5,
    "probe_server_ids": [1, 2, 3],
    "alert_on_down": 1,
    "alert_on_recovery": 1
  }'

Two things worth flagging in that payload:

• check_type is tcp, not tcp_connect or redis or anything Redis-specific. TCP uptime checks open a TCP connection and verify it succeeds within timeout_seconds. They don't speak Redis protocol.
• target is host:port as a single string, not separate fields. The validator rejects whitespace, shell metacharacters, and out-of-range ports.

Response is 201 Created with the new check row and the list of probe server IDs. See the Uptime Checks API reference for every field.

Multi-vantage behavior

You assigned the check to three web servers. Each one runs the probe independently every heartbeat and reports its own result. BoxWatch aggregates the three results:

• 3 of 3 OK → status up. No alert.
• 2 of 3 OK → status degraded. Visible on the dashboard. No alert fires.
• 2 of 3 down → status down (strict majority). After two consecutive down aggregations, an alert fires.
• 3 of 3 down → status down immediately, alert after the second consecutive sample.

The two-tick flap guard is intentional. A single failed probe doesn't wake you up. A sustained majority outage does.

This is why three probes is better than one: with one probe, every transient network glitch on that one box looks like a Redis outage. With three, a single host having a bad day shows up as degraded and you go back to bed.

Step 3: route to Slack and email

Each BoxWatch account has one Slack URL and email is on by default.

1. Dashboard → Account → Notifications.
2. Paste your Slack incoming-webhook URL.
3. Save.

When the check transitions to down, you'll get one Slack message and one email. When it recovers (if alert_on_recovery is on), you'll get a second pair. See Alerts.

What you'll see in the dashboard

The check's detail page shows:

• Current aggregate status (up / degraded / down / pending / paused).
• Per-probe table — one row per probe server with its last result and timestamp.
• A latency chart per probe (the TCP connect time).
• Recent results — last N probe attempts, with status code, error kind, and message when applicable.

A "down" with error_kind: connect_refused means the TCP layer is reaching the host but Redis isn't listening. connect_timeout means the host itself isn't responding within 5 seconds. dns_error means the hostname didn't resolve. These distinctions are usually the first clue when diagnosing an outage.

Common gotchas

• Firewall between agent and Redis. TCP checks fail with connect_timeout when a security group or iptables rule silently drops the SYN. If curl telnet://redis.internal:6379 works from the same box, BoxWatch's check will too.
• Listening on localhost only. If Redis is bound to 127.0.0.1, the check will only succeed when assigned to that exact box. Bind it to the right interface or assign the check to the Redis host itself.
• TLS-wrapped Redis. TCP uptime checks don't do TLS. They open a raw TCP connection. If your Redis listens on a TLS-only port and a successful TCP connect followed by a TLS handshake failure is something you'd call "down," you want this check plus a tls_expiry check on the same target — see TLS cert expiry watching.