{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"the-maintenance-calendar","title":"The hour a week that keeps it alive","url":"https://addaly.com/learn/cloud-and-shipping/the-maintenance-calendar","position":71,"of":74,"minutes":8,"answer":"Everything that keeps a system healthy is recurring and forgettable, so put it in a calendar with intervals, one owner per item and a written note per run, and when you fall behind.","keyIdea":"Everything that keeps a system healthy is recurring and forgettable, so put it in a calendar with intervals, one owner per item and a written note per run, and when you fall behind, restore a backup and review access before anything else."},"body":{"format":"markdown","text":"## Maintenance is not a mood\n\nEverything in this course that keeps a system healthy is recurring: restores get tested, keys get rotated, dependencies get updated, access gets reviewed, costs get checked, capacity gets re-measured. None of it is hard. All of it is forgettable.\n\nThe teams that stay out of trouble are not more disciplined by temperament. They have a written calendar with a named owner per item, and the items are small enough to actually do. The expiry lesson gave you the list of things with dates on them; this is the list of things with *intervals*.\n\n## The calendar\n\n**Weekly: 20 minutes**\n\n- Merge the grouped dependency update pull request, once CI is green.\n- Skim errors from the last seven days: any new group, any big jump.\n- Glance at the cost dashboard for anything unexpected.\n\n**Monthly: one hour**\n\n- Perform a deploy and a rollback, deliberately, and time the rollback.\n- Read the alerts that fired: which were actionable, which were noise, delete or retune the noise.\n- Check backup jobs actually ran, and check the size of the most recent backup is plausible.\n- Review the open security findings from your scanner and either fix or explicitly accept, with a date.\n\n**Quarterly: half a day**\n\n- Restore a backup into a scratch environment and record the time it took.\n- Rotate one credential, end to end, using its runbook.\n- Review who has admin, database and cloud access; remove what is no longer needed.\n- Take one major upgrade from the list.\n- Re-run the load test and compare the ceiling with last quarter's.\n- Read your own runbook as though you had never seen it, and fix what it assumes.\n\n**Annually: one hour**\n\n- Refresh the expiry list: domains, certificates, cards, tokens, contracts, end-of-life dates.\n- Recompute cost per user and the ten-times-users test.\n- Re-read the decisions document and mark anything that is no longer true.\n\n## Make it a real appointment\n\nThree things that decide whether this survives its first busy month:\n\n1. **It is in the calendar with a time**, not on a list. An hour on Friday morning, recurring.\n2. **Each item has one name against it.** Shared ownership on a small team means nobody.\n3. **The output is written down.** A one-line note per item in a file: date, what was done, what was found. Six months of those notes is how you notice that the restore has been getting slower.\n\n## Automate the parts that are honest to automate\n\nMuch of the weekly list should be a bot. Dependency pull requests, certificate expiry checks, backup success reports, cost anomaly alerts, a scheduled job that fails the build when something is expiring within 30 days. Free tooling covers all of it.\n\nWhat should *not* be automated is anything whose value comes from a person looking: the alert review, the access review, the runbook read-through. A green tick from a script that nobody reads is the same as no check at all. This course has made that point about health checks, about verification scripts and about backups, and it is the same failure each time.\n\n## When you are behind\n\nEverybody falls behind. The recovery is not to do six months of maintenance in one weekend; it is to pick the two items with the worst consequences and do those.\n\nFor almost every project, those two are: **restore a backup**, and **review who has access**. One protects the data, the other protects it from people who should no longer reach it. Everything else can wait a fortnight.\n\n## The measure that tells you it is working\n\nCount, over a year, how many of your incidents were caused by something on this list going undone: an expired certificate, an unpatched dependency, a full disk, a backup that had been failing silently. In an unmaintained system that is most of them. In a maintained one it approaches zero, and the incidents you do have are novel.\n\nThat is the return on an hour a week: not the absence of problems, but the absence of the boring ones you already knew how to prevent."},"check":{"question":"A team automates backup verification with a script that emails a success message nightly. A year later a restore fails because the backups contained only one of two databases. What does this illustrate?","options":[{"text":"Backups should be taken more frequently than nightly","correct":false,"tempting":"Frequency affects how much data you lose, not whether the backup contains what you need."},{"text":"The email was not being read, which is the real failure","correct":false,"tempting":"Unread notifications are a genuine problem, but reading them would not have helped: the script was reporting success truthfully about the wrong thing."},{"text":"A check that verifies the job ran is not a check that a restore works, so the quarterly restore drill is the one that would have caught it","correct":true},{"text":"Automation is unreliable and this work should be done manually","correct":false,"tempting":"Overcorrects: automation is right for running the job, and the gap is which property was being verified, not who verified it."}]},"prev":{"slug":"moving-house","title":"Moving to another provider without losing a URL","url":"https://addaly.com/learn/cloud-and-shipping/moving-house"},"next":{"slug":"turning-things-off","title":"Removing a feature, and retiring a site","url":"https://addaly.com/learn/cloud-and-shipping/turning-things-off"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The hour a week that keeps it alive', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/the-maintenance-calendar (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The hour a week that keeps it alive","courseTitle":"Shipping It","module":{"index":8,"slug":"running-it-for-years","title":"Running it for years"},"answer":null,"keyIdea":"Everything that keeps a system healthy is recurring and forgettable, so put it in a calendar with intervals, one owner per item and a written note per run, and when you fall behind, restore a backup and review access before anything else.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"maintenance-is-not-a-mood","runs":[{"text":"Maintenance is not a mood"}]},{"t":"p","runs":[{"text":"Everything in this course that keeps a system healthy is recurring: restores get tested, keys get rotated, dependencies get updated, access gets reviewed, costs get checked, capacity gets re-measured. None of it is hard. All of it is forgettable."}]},{"t":"p","runs":[{"text":"The teams that stay out of trouble are not more disciplined by temperament. They have a written calendar with a named owner per item, and the items are small enough to actually do. The expiry lesson gave you the list of things with dates on them; this is the list of things with "},{"text":"intervals","i":true},{"text":"."}]},{"t":"h2","id":"the-calendar","runs":[{"text":"The calendar"}]},{"t":"p","runs":[{"text":"Weekly: 20 minutes","b":true}]},{"t":"ul","items":[[{"text":"Merge the grouped dependency update pull request, once CI is green."}],[{"text":"Skim errors from the last seven days: any new group, any big jump."}],[{"text":"Glance at the cost dashboard for anything unexpected."}]]},{"t":"p","runs":[{"text":"Monthly: one hour","b":true}]},{"t":"ul","items":[[{"text":"Perform a deploy and a rollback, deliberately, and time the rollback."}],[{"text":"Read the alerts that fired: which were actionable, which were noise, delete or retune the noise."}],[{"text":"Check backup jobs actually ran, and check the size of the most recent backup is plausible."}],[{"text":"Review the open security findings from your scanner and either fix or explicitly accept, with a date."}]]},{"t":"p","runs":[{"text":"Quarterly: half a day","b":true}]},{"t":"ul","items":[[{"text":"Restore a backup into a scratch environment and record the time it took."}],[{"text":"Rotate one credential, end to end, using its runbook."}],[{"text":"Review who has admin, database and cloud access; remove what is no longer needed."}],[{"text":"Take one major upgrade from the list."}],[{"text":"Re-run the load test and compare the ceiling with last quarter’s."}],[{"text":"Read your own runbook as though you had never seen it, and fix what it assumes."}]]},{"t":"p","runs":[{"text":"Annually: one hour","b":true}]},{"t":"ul","items":[[{"text":"Refresh the expiry list: domains, certificates, cards, tokens, contracts, end-of-life dates."}],[{"text":"Recompute cost per user and the ten-times-users test."}],[{"text":"Re-read the decisions document and mark anything that is no longer true."}]]},{"t":"h2","id":"make-it-a-real-appointment","runs":[{"text":"Make it a real appointment"}]},{"t":"p","runs":[{"text":"Three things that decide whether this survives its first busy month:"}]},{"t":"ol","start":1,"items":[[{"text":"It is in the calendar with a time","b":true},{"text":", not on a list. An hour on Friday morning, recurring."}],[{"text":"Each item has one name against it.","b":true},{"text":" Shared ownership on a small team means nobody."}],[{"text":"The output is written down.","b":true},{"text":" A one-line note per item in a file: date, what was done, what was found. Six months of those notes is how you notice that the restore has been getting slower."}]]},{"t":"h2","id":"automate-the-parts-that-are-honest-to-automate","runs":[{"text":"Automate the parts that are honest to automate"}]},{"t":"p","runs":[{"text":"Much of the weekly list should be a bot. Dependency pull requests, certificate expiry checks, backup success reports, cost anomaly alerts, a scheduled job that fails the build when something is expiring within 30 days. Free tooling covers all of it."}]},{"t":"p","runs":[{"text":"What should "},{"text":"not","i":true},{"text":" be automated is anything whose value comes from a person looking: the alert review, the access review, the runbook read-through. A green tick from a script that nobody reads is the same as no check at all. This course has made that point about health checks, about verification scripts and about backups, and it is the same failure each time."}]},{"t":"h2","id":"when-you-are-behind","runs":[{"text":"When you are behind"}]},{"t":"p","runs":[{"text":"Everybody falls behind. The recovery is not to do six months of maintenance in one weekend; it is to pick the two items with the worst consequences and do those."}]},{"t":"p","runs":[{"text":"For almost every project, those two are: "},{"text":"restore a backup","b":true},{"text":", and "},{"text":"review who has access","b":true},{"text":". One protects the data, the other protects it from people who should no longer reach it. Everything else can wait a fortnight."}]},{"t":"h2","id":"the-measure-that-tells-you-it-is-working","runs":[{"text":"The measure that tells you it is working"}]},{"t":"p","runs":[{"text":"Count, over a year, how many of your incidents were caused by something on this list going undone: an expired certificate, an unpatched dependency, a full disk, a backup that had been failing silently. In an unmaintained system that is most of them. In a maintained one it approaches zero, and the incidents you do have are novel."}]},{"t":"p","runs":[{"text":"That is the return on an hour a week: not the absence of problems, but the absence of the boring ones you already knew how to prevent."}]}],"check":{"question":[{"text":"A team automates backup verification with a script that emails a success message nightly. A year later a restore fails because the backups contained only one of two databases. What does this illustrate?"}],"options":[{"text":[{"text":"Backups should be taken more frequently than nightly"}],"correct":false,"tempting":[{"text":"Frequency affects how much data you lose, not whether the backup contains what you need."}]},{"text":[{"text":"The email was not being read, which is the real failure"}],"correct":false,"tempting":[{"text":"Unread notifications are a genuine problem, but reading them would not have helped: the script was reporting success truthfully about the wrong thing."}]},{"text":[{"text":"A check that verifies the job ran is not a check that a restore works, so the quarterly restore drill is the one that would have caught it"}],"correct":true,"tempting":null},{"text":[{"text":"Automation is unreliable and this work should be done manually"}],"correct":false,"tempting":[{"text":"Overcorrects: automation is right for running the job, and the gap is which property was being verified, not who verified it."}]}],"order":[3,0,2,1],"why":null},"prev":{"slug":"moving-house","title":"Moving to another provider without losing a URL","minutes":9},"next":{"slug":"turning-things-off","title":"Removing a feature, and retiring a site","minutes":8}}}