Observability Masterclass | Pingtym Insights

Phase 01: Discovery

DNS Resolution

The journey begins with a question. DNS resolution is the process of translating a human-friendly domain name (like example.com) into a machine-readable IP address.

Pingtym measures the exact duration from the moment the lookup is initiated to the moment the Resolver returns the final record. High DNS latency often points to misconfigured nameservers or sluggish TTL propagation.

The Analogy Looking up a friend's address in a global phonebook before you can even leave your house.

internal/monitor/monitor.goGo 1.22

                        DNSStart: // Record timestamp
                        DNSDone: // Subtract start
                        
                        // Pingtym uses:
                        net.DefaultResolver.LookupIP(ctx, "ip", host)

Phase 02: The Handshake

TCP & TLS Negotiation

Connection isn't just a switch; it's a conversation. First, the TCP Three-Way Handshake establishes a reliable data stream (SYN, SYN-ACK, ACK).

Then, the TLS Handshake negotiates encryption keys. If your TLS metric is high, your server might be struggling with complex cipher suites or a lack of hardware acceleration for SSL processing.

The Analogy Knocking on a door, hearing "Who is it?", and then exchanging a secret code-book before you're allowed to talk.

Trace EventsHardware Timed

                        ConnectStart → ConnectDone
                        TLSHandshakeStart → TLSHandshakeDone
                        
                        // Measures physical wire-time

Phase 03: Server Processing

Latency (TTFB)

This is the "Emerald" metric. Time to First Byte (TTFB) measures the internal delay between receiving a request and generating the very first byte of the response.

This isolates your application's performance from the network. If TTFB is high but DNS/TCP are low, the problem is inside your code—likely a slow database query or a heavy middleware stack.

The Analogy The time between the waiter taking your order and the first appetizer hitting the table.

Server PerformanceBackend Metric

                        GotFirstResponseByte
                        
                        // Pure Server Efficiency
                        TTFB = ttfbDone.Sub(start)

Phase 04: Payload Delivery

Transfer Time

Once the processing is done, the data must travel. Transfer Time is the duration spent downloading the actual body content after the first byte has arrived.

High transfer times usually indicate large asset sizes (images, heavy JS bundles) or limited bandwidth between the server and the visitor.

The Analogy The time it takes to actually eat the entire 5-course meal after it has been served.

Bandwidth MetricNetwork Load

                        // Total duration minus initial wait
                        transfer = FullDuration - TTFB
                        
                        io.Copy(io.Discard, resp.Body)

Phase 05: Identity Validation

SSL Certificates

Trust is transient. Pingtym proactively monitors your SSL certificate expiry dates to prevent "Security Warning" screens that kill user trust.

We check the NotAfter field of your peer certificates and cross-reference them with established Certificate Authorities to ensure your chain of trust is active and valid.

The Analogy Checking the expiration date on your passport before a big international flight.

Security AuditTrust Chain

                        // Peer Certificate Check
                        certs = conn.ConnectionState()
                        expiry = certs[0].NotAfter
                    

Phase 06: Global Correlation

SaaS Context

Infrastructure never exists in a vacuum. Pingtym correlates your local outages with the official status pages of global providers like AWS, Cloudflare, and GitHub.

By ingesting summary.json feeds from statuspage.io and other providers, we help you distinguish between a localized bug and a massive backbone failure.

The Analogy Checking the city-wide news to see if the power is out everywhere or if you just blew a fuse.

Correlation EngineExternal API

                        /api/v2/summary.json
                        
                        // Correlates Infrastructure

Phase 07: Incident Response

Webhook Alerting

Observation without action is just logging. Pingtym fires real-time alerts to your Slack or Discord webhook when your infrastructure needs attention.

The alerting engine uses a 3-strike confirmation model: a DOWN alert is only sent after 3 consecutive failures, eliminating false positives from transient network blips. Recovery (UP) alerts are sent only after a confirmed outage resolves.

To set it up, paste your Slack or Discord webhook URL in the "Alert Webhook" field when adding a monitor. That's it—no configuration files, no routing rules.

The Analogy A smoke detector that waits to confirm real smoke before sounding the alarm—not one that screams every time you make toast.

Webhook PayloadJSON

                        // Sent on DOWN (after 3 failures)

                        // and on UP (recovery)

                        {

                          "text": "🚨 Pingtym Alert 🚨\n

                            Monitor: Primary API\n

                            Status: DOWN\n

                            Latency: 0ms\n

                            Error: connection refused"

                        }