Service Details

The Service Details page provides comprehensive information about a specific monitoring service, including current status, historical check data, performance metrics, and configuration details.

Accessing Service Details

To view service details:

1. Navigate to the Services dashboard
2. Click on the service name in the list

Alternatively:

• Click the View icon (eye) next to the service
• Navigate directly via URL with service ID

Page Layout

Header Section

The header displays:

Service Name — Large heading with the service name.

Action Buttons — Edit Service (open configuration modal) and Back to Services (return to dashboard).

Information Sections

The page is divided into multiple sections:

1. Probe Locations Map (left column)
2. Performance Graph (right column)
3. Service Checks Table (full width)

Probe Locations

Map Display

The Probe Locations section shows:

Purpose — Visual representation of global probe distribution.

Information Displayed — Geographic locations of probes performing checks.

Current Implementation — Placeholder for future map integration.

Planned Features:

• Interactive world map
• Probe location markers
• Per-location status indicators
• Location-specific metrics

Map Dots Show Current State

Each dot on the map reflects the current (last-known) state of that probe location, derived from the most recent check it reported. This is deliberately independent of the page time range — the dots always show "right now," not the selected window.

A location turns gray (stale) when no fresh result has arrived in about twice its check interval, so a probe that has gone quiet is visibly distinct from one that is actively reporting "up." Right after a check-interval change, the staleness window is widened briefly so a location is not flagged stale before its first result on the new cadence lands.

Global Probe Network

Checks are performed from multiple geographic locations:

Benefits:

• Detect regional outages
• Identify geographic performance variations
• Validate global accessibility
• Monitor CDN effectiveness

Future Capabilities:

• Select specific probe locations
• View per-location status
• Compare regional performance
• Identify routing issues

Response Time Breakdown

For HTTP services, the graph in the right column is a bucketed, stacked timing-breakdown chart: instead of one line for "response time," every column shows where the time actually went for that time bucket.

Reading the chart

One column per time bucket. The selected time range is divided into buckets (the same adaptive bucketing used by the compact history strips elsewhere in the app), so a 24-hour view doesn't try to draw thousands of individual checks — buckets widen automatically as the range grows.

Column height = total response time. Each column is partitioned — not summed on top of a separate "total" line — into the phases that make up that request, stacked bottom to top in a fixed order:

1. TCP connect — establishing the connection
2. TLS handshake — certificate negotiation (HTTPS only)
3. Pre-transfer — everything after the handshake, before the request is sent
4. Time to first byte (TTFB) — waiting on the server to start responding
5. Download — receiving the response body

Because the segments partition the total rather than duplicate it, the column height and the sum of its segments always agree — there's no separate "total" series drawn on top to reconcile against.

Colour: phase by position, status by hue

The stack order above never changes, so colour is used to encode status instead of phase. Each column's hue reflects the bucket's outcome, with the phase segments rendered as brightness steps of that hue (darkest at the bottom, lightest at the top):

A bucket where every probe was unreachable, or where no result arrived at all (a missed check cycle), has no column — there is no request duration to plot. This means a red column always represents a request that answered but was unhealthy (a 5xx status, a failed assertion, or an excessively slow response) — never a hard outage, which shows as a gap.

The status strip

Directly beneath the columns, a status strip uses the same bucket boundaries to show green / amber / red / hollow grey. The hollow grey fill is what distinguishes a bucket with no column because of a missed check from one with no column because the service was completely unreachable (red strip, no column) — the chart alone can't tell those apart, since neither has a duration to draw, so the strip carries that distinction. Together: the columns answer "how fast," the strip answers "what happened."

Bucket colour always follows the platform-wide rule: all probes OK is green, some-bad is amber, all-bad is red, and a missed cycle is hollow grey — never red. A result that can't be attributed to a specific probe degrades a bucket rather than marking it fully down.

Choosing a statistic: Mean / p95 / p99 / Max

A selector above the chart lets you choose which statistic each bucket's column represents. The default is Mean.

The chosen statistic is reflected in the page URL, so a link to a p99 view stays on p99 when shared or reloaded.

Interacting with the chart

Hover a column for a tooltip showing the bucket's time range, status (including how many probes failed out of how many reported), the per-phase millisecond breakdown, the total, and the number of checks in the bucket.

Click a column to jump into the Probe Log tab scoped to that bucket's exact time window — a fast way to go from "that column looks slow" or "that column is red" straight to the individual checks behind it.

Latency Range (PING)

For PING services, the graph in the right column is a floating min–max band with an average marker — instead of three tangled lines for min/avg/max RTT, each time bucket draws one shape that shows the spread at a glance.

Reading the chart

One band per time bucket, using the same adaptive bucketing as the HTTP breakdown chart and the compact history strips elsewhere in the app.

Each bucket draws three things:

• A transparent spacer from zero up to the bucket's minimum RTT — it takes up the vertical space but draws nothing, so the band floats instead of sitting on the axis.
• A visible band from the minimum up to the maximum RTT.
• A thin marker rule inside the band showing the average (or p95/p99 — see below).

The band's height is jitter — the spread between the fastest and slowest packet round-trip in that bucket — which is itself a real network-quality signal. A tall, wide-spread band means the network path is unstable even if the average looks fine; a thin band means consistent latency. This is exactly the signal three overlapping min/avg/max lines bury: with lines, a wide spread just looks like the lines briefly diverging and then reconverging, easy to miss at a glance; with a floating band, instability is the shape itself.

Aggregation: never a percentile of a percentile

Bucket aggregation is bottom-up from real per-check values, never computed by re-aggregating already-aggregated numbers:

• Band low = the minimum of each check's minimum RTT in the bucket.
• Band high = the maximum of each check's maximum RTT in the bucket.
• Marker = the mean (or p95/p99) of each check's average RTT in the bucket.

Choosing a statistic: Mean / p95 / p99

A selector above the chart lets you choose which statistic the marker represents. The default is Mean.

Colour and the status strip

The band and its marker follow the same colour and status-strip conventions as the HTTP breakdown chart: hue reflects the bucket's outcome (green / amber / red), a bucket with no reachable check has no band, and the status strip beneath the chart distinguishes a missed cycle (hollow grey) from a fully down one (red, no band) — the platform-wide rule that a bucket only turns red when every reporting probe failed, never for a single failing probe among many.

Interacting with the chart

Hover a bucket for a tooltip showing the time range, status, the low / marker / high values, the jitter (high minus low — the number the band visually represents), the check count, and (when enabled) a drill-in affordance into the Probe Log.

Click a bucket to jump into the Probe Log tab scoped to that bucket's exact time window.

Service Checks Table

Table Overview

The Service Checks Table displays historical check results.

Columns:

Check Status Indicators

Successful Checks:

• Green check mark icon
• HTTP: Status code and response time
• PING: Response time and packet statistics

Failed Checks:

• Red X icon
• Error message or reason
• Diagnostic information

Check Details

HTTP Service Checks:

Successful check shows:

• HTTP status code (e.g., 200, 301)
• Response time in seconds
• Probe location
• Timestamp

Failed check shows:

• Error type (connection, timeout, etc.)
• Error message
• Attempted URL
• Timestamp

PING Service Checks:

Successful check shows:

• Minimum RTT
• Average RTT
• Maximum RTT
• Packet loss percentage
• Probe location

Failed check shows:

• Packet loss percentage (typically 100%)
• Error message
• Target IP/domain
• Timestamp

Table Features

Current Capabilities:

• View recent checks
• See success/failure status
• Review error details
• Sort by timestamp (newest first)

Planned Features:

• Filter by status (success/fail)
• Filter by probe location
• Export check data
• Pagination for large datasets
• Search functionality

Service Configuration

Viewing Configuration

Service configuration is displayed when editing:

1. Click "Edit Service" button
2. Configuration modal opens
3. All parameters displayed in editable form

Configuration Details

All Services:

• Service name
• Project assignment
• Enabled status
• Check interval

HTTP Services:

• URL
• HTTP method
• Authentication type and credentials
• Custom headers
• POST data

PING Services:

• IP address or domain name

Service Management

Editing Service

To modify service configuration:

1. Click "Edit Service" button in header
2. Configuration modal appears
3. Modify desired parameters
4. Click "Save Changes"

Changes take effect immediately for subsequent checks.

Deleting Service

To delete the service:

1. Return to Services dashboard
2. Locate the service
3. Click Delete icon
4. Confirm deletion

Understanding Check History

Check Frequency

Checks appear according to configured interval:

• 1-minute interval: 60 checks per hour
• 3-minute interval: 20 checks per hour
• 5-minute interval: 12 checks per hour
• 10-minute interval: 6 checks per hour

Historical Retention

Check history retention:

Current Implementation:

• All checks stored indefinitely
• No automatic purging
• Full history available

Future Considerations:

• Potential data retention policies
• Archival of old checks
• Summary metrics for historical periods

Check Patterns

Analyze check history for patterns:

Consistent Success:

• Service operating normally
• No intervention needed
• Baseline performance established

Intermittent Failures:

• Investigate underlying causes
• Check for patterns (time of day, etc.)
• Review service logs
• Consider increasing check frequency

Prolonged Outages:

• Immediate attention required
• Review service status
• Check incident reports
• Verify infrastructure

Performance Analysis

Response Time Analysis

HTTP Services:

Monitor response time trends:

Fast Response (<100ms):

• Excellent performance
• Optimal user experience
• Efficient backend

Moderate Response (100–500ms):

• Acceptable performance
• Monitor for degradation
• Consider optimization

Slow Response (>500ms):

• Performance investigation needed
• User experience impact
• Optimization required

PING Services:

Monitor RTT trends:

Low Latency (<50ms):

• Good connectivity
• Efficient routing
• Local or well-connected

Medium Latency (50–150ms):

• Acceptable for most use cases
• Geographic distance factor
• Normal for remote hosts

High Latency (>150ms):

• Geographic distance
• Routing inefficiency
• Potential network issues

Availability Analysis

Calculate uptime percentage:

Uptime % = (Successful Checks / Total Checks) × 100

Target Availability:

• Critical services: 99.9% (8.76 hours downtime/year)
• Important services: 99% (87.6 hours downtime/year)
• Standard services: 95% (18.25 days downtime/year)

Probe Location Distribution

Multi-Location Monitoring

Checks performed from multiple locations provide:

Geographic Coverage:

• Validate global accessibility
• Detect regional issues
• Identify routing problems
• Monitor CDN performance

Redundancy:

• Multiple perspectives
• Reduce false positives
• Comprehensive monitoring

Location-Specific Issues:

• Regional outages
• DNS propagation delays
• Geographic routing problems
• Firewall configuration errors

Troubleshooting from Details Page

Service Always Down

If service consistently fails:

1. Review check error messages
2. Verify service is actually running
3. Test endpoint manually
4. Check firewall rules
5. Verify configuration accuracy

Inconsistent Results

If results vary between checks:

1. Look for patterns in failures
2. Check for intermittent issues
3. Review performance metrics
4. Investigate during failure periods

No Recent Checks

If checks aren't appearing:

1. Verify service is enabled
2. Check interval configuration
3. Ensure probers are operational
4. Refresh the page

Future Enhancements

Planned features for service details:

Advanced Analytics:

• Detailed performance graphs
• Trend analysis
• Anomaly detection
• Predictive alerts

Custom Time Ranges:

• Last hour, day, week, month
• Custom date ranges
• Comparative analysis

Export Capabilities:

• CSV export of check data
• PDF reports
• API access to metrics

Alert Configuration:

• Per-service alert rules
• Notification preferences
• Escalation policies

Related Documentation

• Services Management
• HTTP Monitoring
• PING Monitoring
• Projects
• Global Probes
• API Checks Endpoint