ProgramGuru

Concurrent Website Status Checker

Start with Concurrent Website Status Checker

Learn concurrent website status checker through an executable example, then connect the small demonstration to production code.

What you’ll learn

  • Explain the main purpose of concurrent website status checker.
  • Read and run the complete Go example in this lesson.
  • Apply the concept and recognize common mistakes.

Understand the idea

A site checker fetches multiple URLs concurrently, captures response codes and reports failures. Bound concurrency and enforce HTTP timeouts, because unreachable endpoints must not block the tool forever.

The runnable demo hosts local test pages rather than depending on public website availability.

Visualize how it works

Follow this diagram before executing the example. Check where a value or decision changes what runs next.

Visual explanation for website checkerConcurrency should not make reports nondeterministic.Load URLsStep 1Run bounded workersStep 2Collect status + errorStep 3Print ordered reportStep 4Concurrency should not make reports nondeterministic.
Concurrency should not make reports nondeterministic.

Tools, syntax and practical notes

Real usage: read URLs from flags or a file, validate schemes, use a shared http.Client with timeouts and a concurrency limit, and save a timestamped report. Be respectful of target-site terms and rate limits.

Run a complete Go example

This example is a complete program. Save it as main.go or paste it into the Go Playground.

Go code

package main

import (
	"fmt"
	"net/http"
	"net/http/httptest"
	"sync"
	"time"
)

func main() {
	server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if r.URL.Path == "/missing" {
			http.NotFound(w, r)
			return
		}
		fmt.Fprint(w, "ok")
	}))
	defer server.Close()
	paths := []string{"/ok", "/missing"}
	codes := make([]int, len(paths))
	client := &http.Client{Timeout: 2 * time.Second}
	var wg sync.WaitGroup
	for i, path := range paths {
		wg.Add(1)
		go func(index int, p string) {
			defer wg.Done()
			resp, err := client.Get(server.URL + p)
			if err == nil {
				codes[index] = resp.StatusCode
				resp.Body.Close()
			}
		}(i, path)
	}
	wg.Wait()
	for i, path := range paths {
		fmt.Println(path, codes[i])
	}
}

Output

/ok 200
/missing 404

Trace what the program does

Both requests run concurrently against the local server. Their HTTP status codes are stored by index; printing after Wait produces /ok 200 and /missing 404 in stable order.

Avoid common mistakes

  • Use per-request timeouts and cap worker counts when checking large URL sets.
  • For real websites, handle DNS, TLS and redirect behavior and avoid unauthorized high-volume probing.

Try it yourself

Add a bounded worker pool, response durations and per-URL error messages.

Tip: Edit the example above, predict the output, and run the modified code to test your reasoning.

Check your understanding

What keeps the displayed result order stable?
Choose one answer. You can try again.

Answer and explanation

Store outcomes by URL index and wait for workers

Correct. Both requests run concurrently against the local server.

What you should remember

You have practiced Concurrent Website Status Checker in a small, self-contained program. The important habit is to predict what runs, inspect the actual output and distinguish the language rule from the particular example.

Before continuing, make sure you can explain the program to someone who has not seen it, including the line that changes its result.

Reaching the recap and completing the quizzes are separate milestones.

    Next lesson: Log File Analyzer →