Free guide · Francisco Arrieta · 10 min

Break your own service on purpose and time how long until anything tells you

Take your own site down in a controlled way, with your phone in the state it is actually in at 2am, and write down how long you sat there not knowing

You know your uptime number. You almost certainly don’t know the other one: how long the thing stays broken before a human finds out. Those are different numbers, and only one of them is about you.

Here’s the shape of the bad morning. The site went down at 2:14. You found out at 9:06, from a customer, who opened with “hey, is the site down for you too?” Between those two timestamps you were asleep and the monitoring was working perfectly.

That’s the part people get wrong. The monitor usually isn’t broken. It checked, it noticed, it fired. Everything after the firing is where it fell over, in an email sitting in a folder called Alerts, because you wrote a rule for it in 2023 so it would stop cluttering the inbox.

Every monitoring tool has a Send test alert button, and that button is the reason nobody catches this. You press it while you’re at the desk with the phone unlocked in your hand. The notification arrives. You decide the alerting works. What you tested was whether the vendor can send a message, and you were the easiest recipient it will ever have.

So test the other end instead. Cause the failure yourself, at the hour and in the conditions where it actually happens, and hold a stopwatch.

Uptime measures the machine. The number you need measures you.

Before you start

Fifteen minutes, and something you can take down for two minutes without anyone minding. A staging copy is fine. Production in a quiet hour is fine if you own it and nobody’s mid-checkout.

Your phone, and whatever you already have watching the service. If the honest answer is that nothing is watching it, run the drill anyway. “Nothing arrived” is a result, and you’d rather have it tonight than at 9:06 some morning.

Step 1

Choose the one failure you’re going to cause

Pick a single failure, name it out loud, and make sure you can undo it in one action.

Most people’s list looks like this:

  • The whole service is down
  • The service answers, but the database behind it doesn’t
  • A payment or webhook handler fails while every page still loads
  • A scheduled job stopped running
  • A certificate expired

Choose the one that would cost you the most if it happened tonight. That’s usually the first one, and the first one is also the easiest to cause and undo, so start there.

Write it down. You’re going to compare what you caused against what you were told, and those two things are often not the same failure.

Step 2

Put the phone in the state it’s in at 2am

Not on the desk. Not unlocked. The state it’s genuinely in while you’re asleep.

Turn on whatever you sleep with. On iPhone that’s Do Not Disturb or a Sleep Focus, and Apple’s own description of Do Not Disturb is that it silences calls, alerts and notifications. On Android it’s Do Not Disturb or Bedtime mode under Modes.

Then put the phone face down, on the other side of the room, where it lives at night.

Close the dashboard too. The monitoring tool’s status page, the green tick, the graph, all of it. A dashboard is something you have to be looking at, and at 2am you aren’t looking at anything.

Step 3

Write down the time, then break it

Note the clock time first. Minutes and seconds. This is the number everything else is measured from.

Then cause the failure. Pick whichever of these you can reverse in one action:

  • Stop the process or the container: docker stop <name>, reversed with docker start <name>
  • Suspend or pause the service in your host’s dashboard
  • Point the monitor’s check at a URL that doesn’t exist

The third one is the safe option if you can’t touch the real service, and it’s worth being clear about what it does and doesn’t prove. It exercises the entire alert path, which is what you’re testing. It tells you nothing about whether your check would have noticed a real failure, because you handed it the failure directly.

Now walk away from the laptop.

Step 4

Wait, and record exactly what arrives

Stay away from the phone but within earshot of it, and do nothing else for fifteen minutes.

You’re measuring two things and they aren’t the same thing. Note the clock time if anything makes a sound or lights the screen. That’s an alert reaching you.

Then at the fifteen minute mark, walk over and pick the phone up. Write down what’s actually on it. That’s an alert arriving, which is a lower bar, and it’s often the only one that got cleared.

For everything you find, note the channel it came through and what it said. If a second and a third arrived, note those too, because the order matters. An email at 2:19 and a push notification at 2:41 is a very different night from the reverse.

If the screen is empty, write nothing. That’s your result, and it’s the most useful one this drill produces.

Some waiting is normal and it isn’t the failure. Nothing can tell you the service is down until the next check runs, and checks run on an interval. UptimeRobot’s free plan checks every five minutes. A gap of a few minutes is that interval doing its job. Twenty minutes isn’t, and neither is silence.

Step 5

Put it back, and time the all-clear as well

Undo the failure, and note that time too. Then wait again, up to fifteen minutes, for the message telling you it’s back.

This half gets skipped and it’s half the cost of a real incident. If the recovery message never comes, or comes an hour late, then every alert you get at 2am is a trip to the laptop with no way to know from bed whether it’s already over.

The lag here is real and it’s worth knowing about before you rely on it. UptimeRobot recovers on the next scheduled check, and it gradually spaces its re-checks out the longer a monitor stays down, so the thing that has been broken longest is the thing you hear about recovering last.

Step 6

You now have a timeline. Look at where the biggest gap in it sits, and fix that one thing. Not all of them.

Nothing arrived at all. Check whether the alert has anywhere to go. An alert with no destination is the common version of this and it’s a two minute fix.

It arrived, silently. Your Focus or mode is filtering the app. On iPhone, go to Settings > Focus, choose the Focus, and add the app under Apps so it’s allowed through. On Android, open Settings > Modes, choose the mode, and under Notification filters > Apps allow the app. Google notes that these settings vary by phone, so if the labels don’t match, look for the mode’s notification filters.

It arrived hours later, in a batch. That’s iPhone’s Scheduled Summary, which collects notifications and delivers them at times you set. Apple also says outright that Focus delays the delivery of notifications rather than only muting them. Take the monitoring app out of the summary.

It arrived by email. Email is a channel you check, not a channel that reaches you. Move the alert to something that pushes: the tool’s own app, a phone call, an SMS. If you keep a phone call in the path, allow that number through your Do Not Disturb, or turn on Allow repeat callers on Android, which lets a call through when the same person calls twice within fifteen minutes.

Then put the next drill in the calendar. A fix you haven’t re-tested is a belief, and you already know how that turns out.

A boundary worth knowing about

This drill measures one path, on one night, for one kind of failure. That’s genuinely useful and it isn’t coverage.

The failures it won’t find are the quiet ones. Your check almost certainly asks for the homepage and reads a 200 back, which means the service can be up, and slow, and answering, while checkout is broken and nothing anywhere thinks a thing is wrong. That failure looks identical to a good night from where the monitor is standing.

The other edge is that you tested the path you tested. If you ran the drill on staging, production may have different alert contacts. If you ran it on a Tuesday, the person on call at the weekend may not be in the list at all. Every one of those is another drill, not an assumption.

If you have staff

Run it on somebody else’s phone. Yours is the one path you’d have noticed being broken. Theirs is the one you’re actually relying on the night you’re on a plane.

Test what happens when nobody answers. Most setups have a first person and a theoretical second person, and the handover between them has never once been exercised. Do the drill, then have the first person deliberately ignore it, and find out whether anything reaches anyone else.

Write the two times down somewhere shared. Time to alert, and time to all-clear, with the date. Two numbers on a page beat any opinion about whether the alerting is fine.

The short version

  1. Pick one failure you can cause and undo in a single action, and write it down
  2. Put your phone in its overnight state, across the room, and close the dashboard
  3. Note the clock time, then cause the failure and walk away
  4. Record what arrives, through which channel, and at what time. After fifteen minutes, “nothing” is the answer
  5. Undo the failure and time the all-clear too
  6. Fix the single biggest gap in that timeline, then book the next drill

Sources

Written August 2026. Phone paths checked against Apple’s and Google’s own documentation on 25 August 2026, against iOS 26 and Android 14 and later. Google says outright that these settings vary by handset, so treat the Android path as the shape rather than the exact wording. The intervals quoted are UptimeRobot’s, and yours will differ, so read your own tool’s interval setting before you judge the gap you measure.

Prints to PDF from your browser — colours and all.