How to Monitor Internal Services Behind a Firewall

External monitoring services can't reach services behind your firewall. Your internal APIs, databases, admin panels, and private tools are invisible to traditional uptime monitoring. But they still need monitoring—internal failures cause outages too.

The solution: monitor from inside your network, not outside.

The Internal Service Problem

What External Monitoring Can Reach

Internet
    │
    ├── https://yoursite.com ✓ Monitored
    ├── https://api.yoursite.com ✓ Monitored
    │
    │   Firewall
    │   ─────────────────────────────────
    │
    ├── Internal API (10.0.0.5:8080) ✗ Unreachable
    ├── Database (10.0.0.10:5432) ✗ Unreachable
    ├── Admin Panel (10.0.0.15:3000) ✗ Unreachable
    └── Internal Tools ✗ Unreachable

External monitoring can only see what's publicly exposed. Everything else is a blind spot.

Why Internal Services Matter

Internal failures cascade to external ones:

• Internal API down → Public API returns errors
• Database unreachable → Everything breaks
• Cache server crashed → Performance degrades
• Admin tool down → Can't manage incidents

You need to know about internal failures before they become external ones.

Solutions for Internal Monitoring

Solution 1: Agent-Based Monitoring (Recommended)

Install a monitoring agent inside your network. The agent:

• Runs inside your firewall
• Monitors internal services
• Reports out to your monitoring dashboard
• Doesn't require inbound firewall holes

                    Firewall
                    ─────────────────────
Your Network                            │
┌─────────────────────────────────┐     │
│                                 │     │
│   Internal API  ←──┐            │     │     Monitoring
│   Database      ←──┼── Agent ───┼─────┼───→ Dashboard
│   Admin Panel   ←──┘            │     │     (HTTPS out)
│                                 │     │
└─────────────────────────────────┘     │

Pros:

• No firewall changes needed
• Agent initiates outbound connections
• Simple setup
• Most secure option

Cons:

• Requires agent installation
• Agent needs network access to internal services

Solution 2: Private Monitoring Locations

Some monitoring services offer "private locations"—you run a probe in your network that the service uses for checks.

Pros:

• Uses familiar uptime check interface
• No custom agent needed

Cons:

• More complex setup
• May require Docker/containers
• Limited to what the probe supports

Solution 3: VPN/Tunnel Access

Create a secure tunnel for monitoring traffic:

• VPN connection from monitoring to your network
• SSH tunnel for specific services
• Tailscale or similar for secure access

Pros:

• External monitors can reach internal services
• Works with any monitoring tool

Cons:

• Security considerations
• Additional infrastructure to maintain
• Potential single point of failure

Solution 4: Self-Hosted Monitoring

Run your monitoring entirely inside your network:

• Prometheus + Grafana
• Uptime Kuma
• Nagios

Pros:

• Complete control
• No external dependencies
• Can monitor anything

Cons:

• Must maintain monitoring infrastructure
• Need redundancy for the monitoring itself
• No external perspective

What Internal Services to Monitor

Databases

Internal APIs

Message Queues (Redis, RabbitMQ)

Background Workers

Wakestack for Internal Monitoring

Wakestack's agent can monitor internal services:

How It Works

1. Install agent inside your network
2. Configure internal monitors through dashboard
3. Agent runs checks from inside firewall
4. Reports results to Wakestack

Example Configuration

# Agent monitors these internal services
monitors:
  - name: Internal API
    type: http
    url: http://10.0.0.5:8080/health
    interval: 60s
 
  - name: Database
    type: tcp
    host: 10.0.0.10
    port: 5432
    interval: 60s
 
  - name: Redis
    type: tcp
    host: 10.0.0.20
    port: 6379
    interval: 60s

Combined View

Production Environment
├── Public Endpoints (external monitoring)
│   ├── https://api.example.com ✓
│   └── https://example.com ✓
│
└── Internal Services (agent monitoring)
    ├── Internal API (10.0.0.5:8080) ✓
    ├── Database (10.0.0.10:5432) ✓
    └── Redis (10.0.0.20:6379) ✓

Monitor internal services — Agent supports internal endpoints.

Best Practices

1. Don't Weaken Security for Monitoring

Never:

• Open firewall holes for external monitoring
• Expose internal services publicly
• Skip authentication for monitoring endpoints

Instead:

• Use agent-based monitoring from inside
• Keep firewall rules strict
• Monitor through secure channels

2. Monitor the Monitoring

If your internal monitoring fails, you're blind:

• Monitor the agent process
• Alert if agent stops reporting
• Have redundant monitoring for critical services

3. Use Health Endpoints

Create proper health check endpoints:

// Internal API health endpoint
app.get('/health', (req, res) => {
  // Check dependencies
  const dbHealthy = await checkDatabase();
  const cacheHealthy = await checkRedis();
 
  res.json({
    status: dbHealthy && cacheHealthy ? 'healthy' : 'degraded',
    database: dbHealthy ? 'up' : 'down',
    cache: cacheHealthy ? 'up' : 'down'
  });
});

4. Separate Internal and External Alerts

Different services need different responses:

• Public API down → Immediate alert, all hands
• Internal tool slow → Warning, business hours

Configure alert channels appropriately.

5. Document Internal Architecture

When internal monitoring alerts fire, responders need to know:

• What the service does
• What depends on it
• How to investigate
• How to restart/fix

Common Mistakes

1. Ignoring Internal Services

"We monitor the public endpoints, that's enough."

Until your internal API fails and the public API returns errors with no explanation.

2. Exposing Services for Monitoring

"Let's just open port 8080 to the monitoring service."

Security hole. Use agent-based monitoring instead.

3. No Monitoring for Internal Tools

"It's just the admin panel."

When the admin panel is down during an incident, you can't manage the incident.

4. Same Alert Priority for Everything

Internal tool slightly slow ≠ Production database down

Prioritize alerts based on impact.

Key Takeaways

• External monitoring can't reach services behind firewalls
• Agent-based monitoring provides internal visibility securely
• Don't weaken security for monitoring access
• Monitor databases, internal APIs, queues, and tools
• Internal failures often cause external failures

Related Resources

• Agent-Based Monitoring
• Server Monitoring Guide
• Uptime Monitoring Guide