Umbraco+usync 17, "Failed to create template" - no logs

Hi, running into an issue where on importing templates specifically, we simply get a “Failed to create template” error with no other info and no logs. The files do exist on disk but they don’t show up in the backoffice at all. Re-creating the files every time is not sustainable. Where would you even start with this? It’s not just one template it happens with either, it’s several.

This is running Umbraco 17.1.0 and uSync 17.0.2.

Hi,

I would have a quick look in the logs - see if there is anything more.

but if the (template) files are there on disk and not showing up in the back office, there might be something else going on.

do you have the umbraco site in “Production” mode, ( Runtime Modes | CMS | Umbraco Documentation )

or are you running the site with compiled razor views ?


setup right uSync will cope with this, (e.g. it can still create the templates, but the files on disk, aren’t really a thing).

but they are some of the things that i think can get it the way of template creation.

Hi Kevin,

I’ve just done an import and this is what is logged:

{“@t”:“2026-02-23T09:33:36.7688443Z”,“@mt”:“[uSync {version}] {user} Starting {action} process”,“@tr”:“a1c1d7f42dbe295382a939cff97b10a9”,“@sp”:“0d5f9fabdf9e9e2b”,“version”:“17.0.2”,“user”:“admin”,“action”:“Import”,“SourceContext”:“uSync.BackOffice.Services.SyncActionService”,“ActionId”:“240155d7-b5c3-47f4-9136-2e2aaa973ed0”,“ActionName”:“uSync.Backoffice.Management.Api.Controllers.Actions.uSyncPerformActionController.PerformAction (uSync.Backoffice.Management.Api)”,“RequestId”:“8000011d-0000-cb00-b63f-84710c7967bb”,“RequestPath”:“/umbraco/usync/api/v1/Perform”,“ProcessId”:11808,“ProcessName”:“iisexpress”,“ThreadId”:14,“ApplicationId”:“ed60961800c8605051c938811d07a74c1f533a35”,“MachineName”:“DESKTOP-CO1L9UK”,“Log4NetLevel”:“INFO “,“HttpRequestId”:“6cb23b94-88e5-4070-8141-a84b93b5a1cd”,“HttpRequestNumber”:6,“HttpSessionId”:“d6d77977-cef5-e791-45c8-8d2e5c089bea”}
{”@t”:“2026-02-23T09:33:42.3064320Z”,“@mt”:“[uSync {version}] {user} finished {action} process ({changes}/{count} changes) in ({time:#,#}ms)”,“@r”:[“5,537”],“@tr”:“649ebe2df66f587a00065b11d69fc055”,“@sp”:“7e481fbebb1ed10f”,“version”:“17.0.2”,“user”:“admin”,“action”:“Import”,“changes”:17,“count”:156,“time”:5537,“SourceContext”:“uSync.BackOffice.Services.SyncActionService”,“ActionId”:“240155d7-b5c3-47f4-9136-2e2aaa973ed0”,“ActionName”:“uSync.Backoffice.Management.Api.Controllers.Actions.uSyncPerformActionController.PerformAction (uSync.Backoffice.Management.Api)”,“RequestId”:“8000011f-0000-cb00-b63f-84710c7967bb”,“RequestPath”:“/umbraco/usync/api/v1/Perform”,“ProcessId”:11808,“ProcessName”:“iisexpress”,“ThreadId”:61,“ApplicationId”:“ed60961800c8605051c938811d07a74c1f533a35”,“MachineName”:“DESKTOP-CO1L9UK”,“Log4NetLevel”:"INFO ",“HttpRequestId”:“7cc094db-d64d-474d-a5af-c07b820da222”,“HttpRequestNumber”:7,“HttpSessionId”:“a9df4a07-9376-bfac-b2c3-ab98896e8550”}

The import doesn’t get stuck or anything, it does finish the import, but the templates give the error. This is happening locally and the site is not in Production mode, nor running compiled razor views.

Hi,

It might be worth turning on debug logging for uSync - this should let you see it work through the template creation.

We don’t throw on errors - because uSync doesn’t want to bring your site down! (if people have it on startup). but the templating code has a lot of diffrent paths in it while it tries to find the files on disk and mode ‘s etc.

But it might be in the logs but not a uSync error (it might be coming from when the save is called - so an umbraco entry might tell you something)

Hi,

I’ve enabled debug logging however I’m not sure what I’m looking for. I don’t see anything that stands out. Most of what I see for each type:

Hi,

Yes downside of debug, it makes a lot of things :frowning:

I would go into the uSync folder, and rename/remove everything that isn’t the “Templates” folder. then run an import - as there are no other folders/files you will then only see the logs for the templates.

Ah, good idea. The first things I see is some deletions being processed, I believe we experimented a bit with template/alias names to see if anything would work and it seems that’s what’s in the deletes (the test aliases). Further up it starts working on the templates but again not sure what to look out for :sweat_smile: I can see a few of those “Update Template Result. False “DuplicateAlias”, might be relevant?