borgmatic-collective/borgmatic
borgmatic-collective/borgmatic
Watch
10
76
Fork
You've already forked borgmatic
 59
Code Issues 57 Pull requests 3 Releases 165 Packages 1 Activity Actions 1

Merged Configs and Healthchecks (monitoring) #1338

New issue
Closed
opened 2026-08-05 15:29:30 +00:00 by sshaikh · 3 comments
sshaikh commented 2026-08-05 15:29:30 +00:00
Copy link

What I'm trying to do and why

I'm attempting to use the merging facility to override some options on a per repo basis (say there are two repos).

Previously, the Healthchecks feature would run on the file as a whole, so one entry covering the the start, log and error state of anything that happens.

If I split out the config to a common include, I expect the healthcheck to process twice. Since this is not being overridden, this means these will go to the same healthcheck endpoint. In the worst case, that means if the second repo operation succeeds where the first failed, then the failure might be obscured.

If that's correct, is the expectation to use a separate HC endpoint per file?

Steps to reproduce

include/common.yaml:

#etc
healthchecks:
    # Healthchecks ping URL or UUID to notify when a backup
    # begins, ends, errors, or to send only logs.
    ping_url: https://hc-ping.com/xxx
#etc

repo1.yaml:

<<: !include include/common.yaml
repositories:
  - path: foo
     label: bar

repo2.yaml:

<<: !include include/common.yaml
repositories:
  - path: foo2
     label: bar2

borgmatic version

1.9.14

borgmatic installation method

pip

### What I'm trying to do and why I'm attempting to use the merging facility to override some options on a per repo basis (say there are two repos). Previously, the Healthchecks feature would run on the file as a whole, so one entry covering the the start, log and error state of anything that happens. If I split out the config to a common include, I expect the healthcheck to process twice. Since this is not being overridden, this means these will go to the same healthcheck endpoint. In the worst case, that means if the second repo operation succeeds where the first failed, then the failure might be obscured. If that's correct, is the expectation to use a separate HC endpoint per file? ### Steps to reproduce include/common.yaml: ``` #etc healthchecks: # Healthchecks ping URL or UUID to notify when a backup # begins, ends, errors, or to send only logs. ping_url: https://hc-ping.com/xxx #etc ``` repo1.yaml: ``` <<: !include include/common.yaml repositories: - path: foo label: bar ``` repo2.yaml: ``` <<: !include include/common.yaml repositories: - path: foo2 label: bar2 ``` ### borgmatic version 1.9.14 ### borgmatic installation method pip
witten commented 2026-08-05 16:56:52 +00:00
Owner
Copy link

I think everything you said here is correct. Monitoring hooks currently run at the configuration file level—so start fires before all repositories in a particular configuration file run, and finish fires after them. So yes, a separate Healthchecks endpoint per configuration file makes sense!

I think everything you said here is correct. Monitoring hooks currently run at the configuration file level—so `start` fires before all repositories in a particular configuration file run, and `finish` fires after them. So yes, a separate Healthchecks endpoint per configuration file makes sense!
sshaikh commented 2026-08-05 17:39:01 +00:00
Author
Copy link

Thanks. I've requested a feature to discuss functionality related to this.

Thanks. I've requested a feature to discuss functionality related to this.
witten commented 2026-08-05 18:05:43 +00:00
Owner
Copy link

Sounds good! (For reference: #1339)

Sounds good! (For reference: #1339)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
parallel-borgmatic
command-hook-steps
2.1.10
2.1.9
2.1.8
2.1.7
2.1.6
2.1.5
2.1.4
2.1.3
2.1.2
2.1.1
2.1.0
2.0.13
2.0.12
2.0.11
2.0.10
2.0.9
2.0.8
2.0.7
2.0.6
2.0.5
2.0.4
2.0.3
2.0.2
2.0.1
2.0.0
1.9.14
1.9.13
1.9.12
1.9.11
1.9.10
1.9.9
1.9.8
1.9.7
1.9.6
1.9.5
1.9.4
1.9.3
1.9.2
1.9.1
1.9.0
1.8.14
1.8.13
1.8.12
1.8.11
1.8.10
1.8.9
1.8.8
1.8.7
1.8.6
1.8.5
1.8.4
1.8.3
1.8.2
1.8.1
1.8.0
1.7.15
1.7.14
1.7.13
1.7.12
1.7.11
1.7.10
1.7.9
1.7.8
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.24
1.5.23
1.5.22
1.5.21
1.5.20
1.5.19
1.5.18
1.5.17
1.5.16
1.5.15
1.5.14
1.5.13
1.5.12
1.5.11
1.5.10
1.5.9
1.5.8
1.5.7
1.5.7.dev0
1.5.6
1.5.5
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.22
1.4.21
1.4.20
1.4.19
1.4.18
1.4.17
1.4.16
1.4.15
1.4.14
1.4.13
1.4.12
1.4.11
1.4.10
1.4.9
1.4.8
1.4.7
1.4.6
1.4.5
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.26
1.3.25
1.3.24
1.3.23
1.3.22
1.3.21
1.3.20
1.3.19
1.3.18
1.3.17
1.3.16
1.3.15
1.3.14
1.3.13
1.3.12
1.3.11
1.3.10
1.3.9
1.3.8
1.3.7
1.3.6
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
1.2.18
1.2.17
1.2.16
1.2.15
1.2.14
1.2.13
1.2.12
1.2.11
1.2.10
1.2.9
1.2.8
1.2.7
1.2.6
1.2.5
1.2.4
1.2.3
1.2.2
1.2.1
1.2.0
1.1.15
1.1.14
1.1.13
1.1.12
1.1.11
1.1.10
1.1.9
1.1.7
1.1.6
1.1.5
1.1.4
1.1.3
1.1.2
1.1.1
1.1.0
1.0.3
1.0.2
1.0.1
1.0.0
0.1.8
0.1.7
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
0.0.7
0.0.6
0.0.5
0.0.4
0.0.3
0.0.2
Labels
Clear labels   
blocked

   
breaking

   
bug

   
data loss

   
design finalized

   
good first issue

   
new feature area

   
question / support

   
security

   
waiting for response
No labels
blocked
breaking
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
borgmatic-collective/borgmatic#1338
No description provided.