How do I do this? Each recipe is one job, start to finish: when to use it, what you need, the steps, what the result tells you, and where it stops. No account, no AI required.
A link that “just doesn’t work” is usually a chain of redirects with one bad hop in it. Look at each hop instead of the end result.
You need
The link. Either Node 18 or newer with the redirect tracer, or a terminal with curl.
Steps
Run node redirect-trace.mjs https://example.com/old-page, or curl -sIL https://example.com/old-page and read every HTTP/ and location: line.
Write down each hop: status, then where it points.
Find the first hop that is wrong: a 404 or 5xx, a loop back to a page already visited, a jump from https to http, or a destination you did not expect.
What it tells you
Where the chain breaks, and so who owns the fix: the site you started on, a redirect service, or the destination.
Where it stops
It sees what the server says. It does not run page scripts, log in, or follow a page that refreshes itself. If every hop looks right and the page is still wrong in a browser, the problem is on the page, not in the chain.
RECIPE 02Trace a form that says “Sent” but nothing arrives
“Sent” only means the page handed the message to something. Follow one message through every place it should pass.
You need
Access to the form, the inbox it should reach, and, if you have it, the form service or website dashboard.
Steps
Send one test with a word nobody else would use, like blue-otter-test-7, and note the time.
Search the destination inbox for that word, including spam, junk, promotions and any filters.
Open the form service or site dashboard and look for that submission. Present there but not in the inbox means it was stored but not delivered. Absent there means it never left the page.
Check which address the form sends to. Moved hosts and renamed mailboxes are the usual reason it changed.
Change one thing, send one new test with a new word, and look again.
What it tells you
Which leg broke: the page, the service that stores or sends it, or the inbox that receives it.
Where it stops
If the service shows it sent and the inbox never got it, the next place to look is the mail records for the domain (recipe 03) and the receiving provider’s own logs, which you may need the provider to read for you.
RECIPE 03Check where a domain points
A site that is down for some people and fine for others, or email that stopped after a move, often comes down to where the domain points now.
You need
The domain name and a terminal. nslookup works on Windows, macOS and Linux. dig gives more detail where it is installed.
Steps
Where the website lives: nslookup example.com, or dig +short example.com A.
Where email goes: nslookup -type=mx example.com, or dig +short example.com MX.
Who answers for the domain: nslookup -type=ns example.com, or dig +short example.com NS. This tells you which provider’s settings actually count.
Compare each answer with what your host or email provider says it should be. Their setup page lists the values.
Ask a public resolver too, for example nslookup example.com 1.1.1.1. If your computer and the public resolver disagree, you may be seeing an old cached answer.
What it tells you
Whether the domain points where you think it does, and whose settings to change if it does not.
Where it stops
Changes can take time to reach everyone. This shows the current answer, not why someone set it that way. Change records only in the provider that the NS answer names.
RECIPE 04Prove two files are the same
When someone says “I sent you the latest version”, a fingerprint settles it. Same fingerprint, same bytes.
You need
The file. Nothing else: the file fingerprint runs in your browser and uploads nothing.
Steps
Get the SHA-256 of your copy: the fingerprint tool, or shasum -a 256 file (macOS, Linux), or Get-FileHash file in PowerShell (Windows).
Get the SHA-256 of the other copy the same way, or the one its sender published.
Compare every character. One different character means different files.
What it tells you
Whether the two files are byte for byte identical: a download that arrived whole, a document nobody changed, two people holding the same version.
Where it stops
A match proves sameness, not safety or correctness. A file can be identical and still wrong.
RECIPE 05Organize a technical problem before you ask for help
Most of the time spent on a problem is spent finding out what it is. Ten minutes of sorting saves the person helping you an hour, and sometimes solves it.
You need
Whatever you have: screenshots, error text, dates. The Problem MRI runs on your device and sends nothing.
Steps
Write what changed, and when. “Nothing I know of” is an answer.
Write what you expected and what happened instead, in one sentence each.
Split what you have seen yourself from what you were told or suspect.
List the records you have: an error message, a screenshot, an email, the date it last worked.
List what you already tried, so nobody repeats it.
What it tells you
What is known, what is assumed, what is missing, and the first thing worth testing. The Bring the Problem baton is the printable version.
Where it stops
It organizes the problem. It does not diagnose it. That takes a test, which is the next step.